First understand...Different between Layers and tiers
Before going any further, though, let me clarify the difference that exists between two terms that are sometimes used interchangeably - layer and tier.
Not that using layer and tier interchangeably is a mistake per se in all situations - and, frankly, I often use these terms as they were synonyms. Fact is, however, they are not synonyms.
A layer refers to pieces of software that are logically separated, but typically live within the same process and machine.
A tier, instead, refers to pieces of software that live in distinct processes or AppDomains or machines. You can allocate a layer on a tier but not vice versa. You can have multiple layers on the same tier. A tier refers to physical separation; a layer is about logical separation. So if you take it literally a business tier is a distinct server where you run the code that forms the business logic.
Hope you understand... Click below .. to earn more....
So the Entity Framework Project...
Entity Framework is often presented as an O/RM tool. Not certainly a wrong statement, but there's more I believe. My idea is that EF was not devised to be a classic O/RM like NHibernate and other commercial tools. The point here is not determining whether this was the right or wrong approach; fact is, that in my opinion the word "framework" says a lot about the original intentions and the changes introduced on the fly with EF4.
EF takes you to create or infer an abstract model (the EDMX file) based on which the visual designer will actually create source files for recognized entities and relationships. In v1, you had no control over the generation of files. The auto-generated files define classes that inherit from EF provided classes thus leaving the entire object model dependent on the Entity Framework assemblies.
When EF auto-generates source code for entities in the model it puts in the same layer entities and the gateway object to the persistence layer. As I see things, this is an even bigger issue. EF4 doesn't solve it in a clear way; it only leaves you some room for manipulating the project so that entities and gateway object (the object context class) end up in distinct assemblies you can deploy to distinct tiers if necessary. The following class does logically belong to the data access layer, not to the business layer.
This means that when you use EF to create the assembly for the domain logic and entities you should manage to move this class to a distinct project. Just impossible to do in EF1, this can be done only with some tricks in EF4 and only if you choose to go with POCO or self-tracking entities. (See Figure 1.)
Figure 1: A project where EF context object has been moved to the DAL project.
Figure 1 shows a Visual Studio solution made of two distinct assemblies - Model and DAL - built from the same source EDMX designer file. The Model assembly incorporates the EDMX item and the POCO artifact item generator. (Same if you use Self-tracking entities.) The item generator produces two T4 template files - context and entities. The T4 template for the context produces the object context object specific for the model; the other T4 template produces the entity classes. By default, both T4 templates belong to the same assembly. To keep them separate - entities are business, context is DAL - create a new project for the DAL and add to it the existing context T4 file as a link. You choose "Add existing item" from the project context menu, locate the context T4 file and add it as a link, as in Figure 2.
Figure 2: Adding an existing item as a link.
Visual Studio will process again the T4 template and add auto-generated files to the current project.
It turns out that Entity Framework oversimplifies the creation of layered applications mixing together elements that logically belongs to the data access layer with entities which clearly belong to the business layer.
Summary
Is everything wrong with EF, even in version 4? EF4 is significantly better than v1 and for a number of reasons. At the end of the day, there begin to be features in EF4 that, properly used, can enable some sort of tool-assisted, domain-driven design in .NET. These features, however, are not yet fully integrated in the designer and the framework itself. I'm referring to the T4 machinery discussed earlier but also to the upcoming Code First feature. EF1 could be used only in a very limited number of realistic scenarios. EF4 is much more widely usable, but you need to be aware of a number of things and pay attention to place the right boundaries between your layers and tiers. Looking forward for the next EF...
