Question

在我的工作中，我们使用实体框架进行数据访问。我正在创建一个数据访问层，一个业务访问层和一些不同类型的项目来访问BLL（用于与客户端应用程序交互的webAPI，多个MVC网站和一些不同的桌面WinForm应用程序）。

我将DTO添加到名为“ DTO”的单独项目中。此解决方案中的该项目的目标是拥有一个DLL，其中包含所有来回传递的类和接口的定义。这样，可以将这个项目创建为其他解决方案中的git子模块，并可以更新以供所有UI项目共同使用。我不会在所有UI上工作，因为我们将更多开发人员带入该项目，并且可能需要多个VS解决方案。

我的想法是让数据访问层回传并接收DTO而不是实体对象。这将使过程完全解耦。

如果我们曾经想用DAL替换DAL，只要它遵循DTO项目中定义的接口，那我们就可以了。我还认为这将使测试更加容易，因为我可以用一个项目替换DAL来生成诸如Seed.net之类的DTO。鉴于我们的环境，更换BTW的可能性很大。

添加这一层复杂性是否不好或违反设计标准？有什么我想念的吗？

Answer 1

这就是我的工作方式，并且已经在Cloud World工作了几年，这似乎是每个人工作的方式。通常，您有以下项目（每个项目都构建到单独的Assembly）

- REST controllers
- Models 
    that are used to pass information between Controller layer and Business Logic
- Business Logic Interfaces  (like ImyService)
- Business Logic  (like myService)
- DTOs
- IRepository (like ImyRepo)
- Repository (like myRepo)
     --> this is the same as DAL.

这样做的好处是，如果添加了依赖倒置（IoC），则可以进行模拟回购，以隔离和测试服务（业务逻辑）层，等等，方法是将其注入NUnit单元测试中

业内人士（包括我在内）经常使用AutoMapper将模型从DTO转换为实体，反之亦然。

DTO，数据层和要返回的类型

1 个答案: