之前经常看到有人问使用了ADO.NET Entity Framework或Linq to SQL的项目该如何分层。EF或Linq2SQL自己生成了一个实体类，由于一般实体类都贯穿整个项目，如果把这个自动生成的实体类作为整个项目实体类的一部分，那么整个项目中的大多数类都将对数据访问层有依赖。当数据库结构变动或者数据访问层有变化时，整个项目很可能随之而动，这样的设计并不是很好。但是在此之前MS给的一些Sample中，大多都使用了自动生成的实体类作为整个项目的实体类，可能之前的Sample都比较小的缘故吧。我也想过专门写个转换类用于在dbml和edm与实体类之间转换，不过总感觉不是很好。这里还有篇博客也是讲在ADO.NET EF中分层架构的：http://blogs.msdn.com/cesardelatorre/archive/2008/09/04/updating-data-using-entity-framework-in-n-tier-and-n-layer-applications-short-lived-ef-contexts.aspx。
前几天看到了Oxite的消息（http://news.cnblogs.com/n/43866/），就下来看了下他的架构。它的做法是在项目中定义实体类接口。BLL和UI使用该接口编程。DAL中使用了一个在数据访问层中使用的实体类继承这些项目中的实体类接口。以用户实体类为例，在Oxite.Data下定义一个IUser接口。BLL和UI中均使用该接口作为实体类。而在DAL（Oxite.LinqToSqlDataProvider）中可以找到一个PartialClasses.cs文件，在这个文件里实现了各个实体类接口。在这里我们可以找到partial class oxite_User : IUser，它实现了IUser接口，而它又是一个partial类，另外半个部分就是在dbml文件中。再看partial class oxite_User : IUser中各属性的代码，比如public Guid ID，它只是将赋给ID的值传给UserID，然后取的时候把UserID的值取出来，而UserID是在dbml(edm)中定义的，所以可以用Linq to SQL(Linq to Entity)对它操作并反映到数据库中，ID又实现了接口中的ID属性，这样就把实体类和dbml(edm)联系起来了而且其他项目只会依赖数据访问层接口和实体类接口而不会依赖数据访问层。另外还有一个细节就是DAL中的每个类都有Savechanges方法，当所有有关联的更新、插入、删除操作方法都完成以后再调用这个方法可以减少打开关闭数据库的次数，增高效率。虽然Oxite用的是Linq to SQL，但使用 ADO.NET Entity Framework 的项目也可参考此方法。