DTO和UnitOfWork模式是一种为Web应用程序设计DAL的好方法吗？

Question

我正在使用实体框架实现DAL.在我们的应用程序中,我们有三个层(DAL,业务层和演示文稿).这是一个网络应用程序.当我们开始实现DAL时,我们的团队认为DAL应该有类,其方法接收业务层上的服务给出的ObjectContext并对其进行操作.这个决定背后的基本原理是不同的ObjectContexts看到不同的DB状态,因此由于外键匹配和其他不一致的问题,一些操作可能被拒绝.

我们注意到从服务层生成和传播对象上下文会在层之间产生高耦合.因此,我们决定使用由Automapper映射的DTO(不是非托管实体或自我跟踪实体,主张高耦合,将实体暴露给上层和低效率)和UnitOfWork.所以,这是我的问题:

1. 这是设计Web应用程序的DAL的正确方法吗？为什么？
2. 如果对1回答"是",那么如何将DTO的概念与UnitOfWork模式相协调？
3. 如果对"1"回答"否",这可能是为Web应用程序设计DAL的正确方法吗？

如果可能的话,请提供支持您答案的参考书目.

关于目前的设计:

该应用程序计划在三个层次上开发:演示,业务和DAL.业务层有外观和服务

有一个名为ITransaction的接口(只有两种处理和保存更改的方法)仅在服务中可见.为了管理事务,有一个类Transaction,它扩展了ObjectContext和ITransaction.我们已经设计了这一点,考虑到在业务层我们不希望其他ObjectContext方法可访问.

在DAL上,我们使用两个泛型类型创建了一个抽象存储库(一个用于实体,另一个用于其关联的DTO).此存储库具有以通​​用方式实现的CRUD方法和两个通用方法,以使用AutoMapper映射通用存储库的DTO和实体.抽象存储库构造函数将ITransaction作为参数,并且它期望ITransaction是ObjectContext,以便将其分配给其检测到的ObjectContext属性.

具体的存储库应该只接收和返回.net类型和DTO.

我们现在面临这个问题:创建的泛型方法不会为附加实体生成临时或持久ID(直到我们使用SaveChanges(),因此打破了我们想要的事务性); 这意味着服务方法无法使用它来关联BL中的DTO

Answer 1

这里有很多事情......我要做的假设是你使用的是3层架构.也就是说,我不清楚你做出的一些设计决定以及制作它们背后的动机是什么.一般来说,我会说你的ObjectContext不应该在你的类中传递.应该有某种管理器或存储库类来处理连接管理.这解决了您的DB状态管理问题.我发现存储库模式在这里运行得很好.从那里,您应该能够相当容易地实现工作单元模式,因为您的连接管理将在一个地方处理.鉴于我对您的架构的了解,我会说您应该使用POCO策略.使用POCO并不能将您与任何ORM提供商紧密联系在一起.优点是您的POCO将能够与您的ObjectContext进行交互(可能通过某种类型的存储库),这将使您可以看到更改跟踪.同样,从那里,您将能够实现工作单元(事务)模式,以便您完全控制业务事务的行为方式.我发现这是一篇非常有用的文章,用于解释所有这些如何组合在一起.代码是错误的,但准确地说明了您所描述的架构类型的最佳实践:存储库,规范和工作单元实现

我对问题1的答案的简短版本是"否".以上链接提供了我认为更适合您的方法.