Domain Logic in Service Layer exposed as WCF service

business-logicentity-framework

I am designing an enterprise solution which consists of modularized products within a product range using Entity Framework code first to define the domain model and provide the data access.

e.g. Solutions:

ProductRange.Authentication
ProductRange.Gateway
ProductRange.OrderSystem
ProductRange.MarketingSystem

Each of these products (solutions) will have similar layers, currently:

Projects in each solution:

ProductRange.OrderSystem.Model (contains code first POCOs)
ProductRange.OrderSystem.DataContext (contains the dbContext)
ProductRange.OrderSystem.DataAccess (contains the Generic Repository)
ProductRange.OrderSystem.Service.DomainLogic (contains business logic)
ProductRange.OrderSystem.Service.ApplicationLogic (contains application logic)
ProductRange.OrderSystem.Presentation.AdminWebsite
ProductRange.OrderSystem.Presentation.CustomerWebsite

Some of the products will need to access the domain logic of another product, especially they will all need to access the ProductRange.Authentication but also ProductRange.MarketingSystem will need to query ProductRange.OrderSystem

I am thinking to expose the domain logic between products in the range via a WCF service. But I will also need to reference the product locally (e.g. creating project references).

How should I go about implementing this? Should I create a WCF service e.g. ProductRange.OrderSystem.WCF which calls the domain logic and exposes it or should my domain logic itsself be a WCF service? If the latter, would I always have to reference my domain logic via the WCF, even from the local ApplicationLogic?

I guess I am looking for some guidance about what layers to have and how best to provide inter connectivity between the solutions.

Best Answer

Here is my two cents worth, I tried to find support for my "WCF is just an interface" on google but have had no luck. I will try again this evening if I get the chance.

The way I was taught and have always approached this is that WCF is just another interface (using the term interface in the way that "GUI" uses it not as the .Net keyword), specifically a way to access code over a network (or internet etc.) I always have a separate class library(s) that the WCF service delegates to for all functionality not related to WCF.

That class library is designed to be usable from any .Net code on the same machine.

The WCF service will do the work to make the library consumable by a variety of languages over the wire. It may translate .Net types to more generic types, lists to arrays for example, or it may add compression for performance reasons.

So if you are consuming the library from .Net code on the same machine I would go directly against the class library. You may want to install this in the GAC for version control.

Of course if the service is stateful then you may want to code against it for simplicity's sake.

Edit. I thought of another reason you might want to bypass WCF locally. For performance reasons a WCF Client should never be "chatty" it is better to make fewer calls that pull in more data, running against a DLL this limitation is not important. So your class library could expose methods that you would not want to expose over WCF.

Related Topic