MVC Onion 架构，一些问题答案

【问题标题】：MVC Onion architecture, some questionsMVC Onion 架构，一些问题
【发布时间】：2015-05-07 00:20:08
【问题描述】：

我正在使用 Asp.net MVC 5、Web Api 2 和实体框架创建一个项目。我用洋葱架构设计它，所以我有一个 DAL、服务和 UI 层。

我的 DAL 层包含 UnitOfWork 和存储库，我的服务层包含业务案例服务。

但我有以下问题：

在哪里使用工作单元保存（或提交）方法？，在服务层还是在 UI 层？如果我在服务层使用它，我该如何处理跨多个服务的情况？
我正在使用 DTO 进行 webapi 操作，服务层应该返回 DTO 还是应该在 UI 层中完成映射？
DTO 应该在单独的项目中还是在 UI 项目中？如果它们在单独的项目中，我应该使用 MVC 属性进行验证吗？

【问题讨论】：

EF 上的存储库不好，mkaaaay？
@Sippy 如果您曾经让经理/架构师在项目中期改变他/她对您的数据访问技术的想法，那么您就会知道在数据访问框架上拥有一个抽象层的价值。因此，不，EF（或任何 ORM）之上的存储库如果封装了 ORM，则还不错。
@Sippy 这还不错，大多数时候没有必要，但我确实需要抽象所有实体框架实现，因为 BrianDriscoll 说最终可能会有数据访问更改。
@BrianDriscoll 同意。我经常创建相同的东西，以便可以在 Mongodb 和 SQL Azure 之间进行交换。我认为 Sippy 可能指的是每个类型模式的存储库的不良做法。
也许是对问题 1 的提示，在 DDD（域驱动设计）中，您区分 应用程序服务 和 域服务。 应用程序服务将代表单独的用例，而域服务表示对您的域模型的操作。在这个空间中，工作单元通常在 应用程序服务 中进行管理，该服务可以组合多个 域服务 以在您的应用程序中实现给定的用例。

标签： c# asp.net-mvc asp.net-web-api n-tier-architecture onion-architecture

【解决方案1】：

您的工作单元应该存在于您的服务层中。对服务的每次调用都包含单个工作单元内的业务事务。

    public ServiceResponse<Patient> Save(Patient patient, string userName)
    {
        Func<Patient> func = delegate
        {
            Authorize(patient, userName);
            Validate(patient, new PatientValidator());

            using (var context = _contextFactory())
            {
                return context.Save(patient, userName);
            }
        };
        return this.Execute(func);
    }

服务层应该返回您的业务实体，任何用于网络通信/json格式的映射都应该在web api中完成。这样可以最大限度地重复使用您的服务。

如果您通过 DTO 指代您用于跨线/json 序列化的对象，那么它们应该与 Web Api 保持在同一个项目中。这可能与您拥有 UI 的项目相同，也可能不同。如果您使用 Web Api，我建议使用 FluentValidation 等验证库。

使用 C#、EF、Web Api 的 Onion 架构 https://github.com/carbonrobot/FullStackEF 示例

【讨论】：

谢谢，还有一个问题，你为什么要把所有的保存函数都包装在一个委托中？
所以我可以尝试一次...捕获所有方法并返回标准格式的响应对象。它使来自 WebApi 等客户端的调用更加干净，您可以使用常用方法处理响应。在那个 try...catch 中也可以记录。由于所有操作都发生在该方法内，所有错误都将被捕获、记录和处理。
我要补充一点，您的业务对象与您的实体框架模型不同。 blog.8thlight.com/uncle-bob/2013/10/01/Dance-You-Imps.html
@ChrisMcKenzie 我不同意这一点。拥有单独的模型不是必需的 b/c 您可以以任何您想要的方式为您的域建模，并且 EF 将处理映射细节。应该没有阻抗不匹配。