Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
What's the different between application and domain logic in your example? –  CodeART Sep 27 '13 at 13:15

2 Answers 2

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.

share|improve this answer

What you have to ask is, what model is my code going to execute in? If it is going to execute wholly within a single machine, there's no point in a WCF service. If it is going to execute in a networked model, placing logic in a WCF service for the clients to call makes sense IF the client(s) will not have access to a resource (e.g. database)

Practically speaking, your domain logic classes should be exposed as interfaces to the consuming clients, so that if you decide to change your implementation from single machine to WCF or REST your consumer classes won't know the difference. -PatFromCanada alluded to this

Your 'layers' should be triaged along the same principle, only create separate projects for separate files to be deployed. Separate 'layers' by namespaces

share|improve this answer
    
Why? The System may be single-tier but peer-to-peer in which case the client is the WCF service. Alternatively, n-Tier topologies that share data amongst clients (irrespective of whether there is a database) will have a server WCF service. With regards to resources, you should avoid having clients that talk directly to a database due to scale-ability concerns hence the need to a WCF service containing your logic. –  Micky Duncan Apr 28 at 7:13
    
Micky, I'm not sure what you're asking. I covered the need to separate contracts and implementations so that specific cases could be implemented as needed with little breaking changes. There shouldn't be an automatic assumption that clients must avoid talking to the database, there may not be that many clients, and simply having a WCF service does not eliminate the load of many clients. Design decisions such as caching, load balancing, sharding etc. do this. –  Kevin May 6 at 13:22
    
I said "avoid" not "automatic". A well-designed WCF service can purposely throttle incoming requests so as to avoid thrashing not just the back-end but also the DB-layer. Architectural (not "design") decisions such as caching, load-balancing and sharding always help, but a better designed system scales even better without these expensive cliched options. The use of queued messaging instead of RPC for instance - a far more efficient choice. soapatterns.org/design_patterns/asynchronous_queuing –  Micky Duncan May 10 at 14:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.