Layered Architecture in Entity Framework 4.0

Question

Hi I am trying architect a small project. I planning to have Data acess, Business Service, WcfService, UI Layer.

I am trying to use EF 4.0 and MVC 2.0. My question is where to generate the entities and ObjectContext through EF. I initially planned it in DataAccess. but to make entities available across all layer I have to reference DataAccess dll across all layers (which is not a Good approach).

Can I make entities in a new layer called Entities and leave ObjectContext in DA. How well it works.

Basic difference between Entities and POCO? (both should be generated by EF).

Is these Entities are available as DataContract (Seralized) by default?

I am trying to avoid repeating the code as much as possible. let me know how will this work.

Thanks

Answer 1

I would recommend taking a look at a 'real-world' sample application called NerdDinner and 185-page PDF walkthrough 'how-each-line-was-written' on Code Plex.

Running app is here: http://www.nerddinner.com/

NerdDinner should be suitable for a small project - you will save a lot of overhead of a more complex solution. Otherwise you could introduce DTO objects between layers and use AutoMapper to reduce mundane 'property-by-property-copy' code.

Answer 2

Business Logic should be cleanly separated from Data Access; as you've correctly said, putting common objects to pass between all layers in the Data Access is bad.

• Use your POCO's to pass data between layers, define these in a common assembly that's very free of dependencies (because all projects that need to exchange data will need to reference it.
• Separate the Business Logic and Data Access with an interface, the interface will define the methods that are called to pass data in and out - and that data will be passed either as a primative base type (int, string, bool, etc) or a POCO (defined in your common assembly).
• Within your data Access impementation use what ever you want - which in your case is EF. This means you'll have to convert the EF objects into POCOs but it means your architecture is clean.

But how would I create POCO (in code generation) as like Entities?

I work from the point of view that the Business Logic is where things "start" conceptually; to say that it embodies the Domain Model would also be fairly accurate.

POCO's are how we pass the information around - and for the most part their design will be driven by the needs of the Business Logic (or Domain Model). In the case of the Domain Model / DDD way of thinking the POCO's could possibly be part of that domain (at this point I'm still unsure if that's an issue or not).

So - how they are generated (conceptually) is by the needs of the Business Logic; however, if performance is a key aspect of your requirements you might also have some that are driven by performance related issues (such as getting a lot of data back in one big DTO rather than many more discrete calls).

How they are physcially generated? Well, I write them either by hand or using a small tool I hacked together. I tend to use Structs (and Collections) for my POCO's but you could use classes instead.

I haven't looked into generating auto-magically off the Business Logic or Domain Model for a couple of reasons:

• It's hard.
• Once generated they don't tend to change much - nor would you want to if they are used by all your assembilies, you'd quickly break your whole system.
• I build different POCO's for different reasons, and that's definately a human judgement kind of thing.

Answer 3

Hey I recently looked at this article. This is what i was looking for. POCO's can't be used in WCF scenario. The best thing to use would be Self tracking entities and for this we can use t4 templates for code generation. I idle answer for my question would be Self tracking entities.

The advantage of using STE is explained in this article clearly.