3
从架构上讲,诸如Microsoft的Entity Framework之类的数据库抽象层是否使对单独的数据访问层的需求无效?
原来的样子 多年以来,我一直在组织软件解决方案,例如: 数据访问层(DAL),用于抽象访问数据的业务 业务逻辑层(BLL),用于将业务规则应用于数据集,处理身份验证等。 实用程序(Util)只是我逐渐建立的常用实用程序方法的库。 表示层当然可以是Web,桌面,移动等。 现在的样子 在过去的四年左右的时间里,我一直在使用Microsoft的Entity Framework(我主要是.NET开发人员),并且由于Entity Framework已经完成了DAL工作,因此我发现拥有DAL变得越来越麻烦。我的DAL曾经做过的工作:它抽象了针对数据库运行CRUD的业务。 因此,我通常以一个DAL结束,该DAL具有如下方法的集合: public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 然后,在BLL中,该方法将按如下方式使用: public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } 当然,这是一个简单的示例,因为BLL通常会应用多行逻辑,但是在这样有限的范围内维护DAL似乎有点多余。 放弃DAL并像这样简单地编写我的BLL方法会不会更好: public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …