Exposing business logic as WCF service

Question

I'm working on a middle-tier project which encapsulates the business logic (uses a DAL layer, and serves a web application server [ASP.net]) of a product deployed in a LAN. The BL serves as a bunch of services and data objects that are invoked upon user action.

At present times, the DAL acts as a separate application whereas the BL uses it, but is consumed by the web application as a DLL. Both the DAL and the web application are deployed on different servers inside organization, and since the BL DLL is consumed by the web application, it resides in the same server.

The worst thing about exposing the BL as a DLL is that we lost track with what we expose. Deployment is not such a big issue since mostly, product versions are deployed together.

Would you recommend migrating from DLL to WCF service? If so, why? Do you know anyone who had a similar experience?

Answer 1

The main question to ask yourself is Why Should I (as in what would I gain by) adding WCF to my project. You would gain scalability, but at the cost of increase complexity. Do you need scalability? Flexibility in deployments (different layers can more easily be on different development schedules) is another benefit, but you mentioned that it was a low priority.

I am currently working in an environment with C# WebParts hitting Java WebServices, We have fought back and forth about versioning, tight and loose coupling, APIs, and more, but we always focus on ROI. How much will this architecture change cost over the life cycle of the project, versus how much will we save in maintenance and development cost.

I would say do it. You can add your WCF Service on the same machine that is currently running your web. I believe separation of concerns, flexibility, and scalability would be worth it, as the change should be minimally invasive.

Answer 2

My recommendation would be to move the business logic onto the same server that has the data access layer, then exposed the business logic as web services using WCF. The web user interface would then make use of the business logic by interacting with the services.

Therefore my answer is yes to your question, I would recommend to migrated from DLL to WCF service.

In some sense you can look at the web application as the presentation layer. The presentation layer and the business logic are two different layers. Of course you can deploy both on the same host. However, in most cases you are better off to deploy business logic and data access on the same host.

I would go even one step further and recommend assessing whether you have a need to expose the data access layer (DAL) via services. If you don't then combining both the data access layer and the business logic into a set of services may be beneficial.

Conceptually a service encapsulates its data and therefore the data access would be an internal detail of a particular service. Equally a service offers pieces of business logic. Therefore creating vertical slices of functionality covering both the business logic and the data access for each slice in a separate service often gives a good level of granularity and modularization.

Of course you may have additional factors that may influence your choices.

Answer 3

I've worked on a lot of projects that had separate business logic and web layers. Some were divided into WCF services, some were consumed as DLL's.

The way I prefer to use shared internal libraries is to include the shared (common) libraries project in the solutions it's used in.

• WebApp Solution
  • Business Project
  • Web Project

Then I have immediate visibility into that project. You have to make sure your team understands changing the business project will affect other products, but most of the time I haven't had any issues.

Exposing a shared library as a WCF (or WebAPI) service to be used internally adds quite a bit of complexity, and from my experience should only be done when there's a significant advantage to do so.

If you have cpu intensive processing, that's a great reason to use web services. you can scale up the hardware or add more servers when needed, and if your service server crashes, it doesn't take down the web host.

If you need to expose data to a 3rd party, however I'd use a shared library inside of a WCF or WebAPI application, and only expose what that 3rd party needs.

• Publicly Exposed Service Solution
  • Business Project
  • Public Service Project (Only exposes limited data, extensive security)

I've heard that you can separate your data layer from your web app layer using services for security, but I haven't experienced that use case first hand.