WCF Service and Entity Framework n tier application issues

0
votes

I am developing WCF Service which is a part of bigger system. The Service would provide some business logic and will be connected to the database through Entity Framework (using model-first). I see there are many different ways of coworking Entity Framework with WCF Service (basic entities, DTOs, self-tracking entities, POCOs, etc.). My basic requirements:

  • The Service is built for thin clients (and other Services), most of the logic is on its side, so it's not any CRUD app (WCF Data Services are not for me)
  • Different clients need data with different levels of granularity, so for the same entity in database there will be different data contracts

Due to my requirements my vision how it should be built is the closest to (I think it's the closest to DTOs approach): http://www.codeproject.com/Articles/127395/Implementing-a-WCF-Service-with-Entity-Framework

But I think that the Data Acces Layer should be separated from the logic of the Service (2 assemblies: projects, namespaces, dll's, but working as one application). In this case I have some issues what should each of those 2 layers do: should all the logic be done in the service and DAL would be used just as CRUD? Or should Service be responsible only for the clear business logic, while whole database logic (specific queries using linq) would be done in DAL (many more specific methods exposed by DAL)? Also what is important which objects should be sent beetwen those 2 layers: data contracts, entities or additional model?

Is my approach OK in mentioned situation?

1
wcfentity-frameworkn-tier-architecture

1 Answers

1
votes

Before SOA, N- or 3- Tier architectures generally had a dedicated Business Layer. If you feel strongly enough about the separation of concerns (or if you think that you might get some reuse of your business functions from non-service consumers), why not move your business logic out of your service layer? (but don't put business logic in your DAL)

However, if your service layer does offer data query services as well as transactional ones, then the business layer isn't needed for these services - take a look at CQRS type design patterns here.

If you need to have control over the XML format of your entities (Names, xmlns etc), you will probably want to build custom WCF DataContract or MessageContract entities. However, if you don't care what the data looks like across the wire, you could simply use the EF Entity classes (as long as they aren't Context bound - i.e. if use POCOs with EF). If you don't attribute the POCOs with DataContract etc, the default behaviour of DataContractSerializer is to serialize public properties.

So you could wind up with the following assembly 'layers' (bottom up)

  • DAL Entities for EF (either ObjectContext bound or POCO)
  • EF DAL
  • Business Layer (for Transactional service methods only - bypassed for Queries)
  • Possibly separate WCF Entities, where you map your POCO / DAL BE's to DataContract / MessageContract
  • WCF Service Layer