分层应用程序中共享层中的实体（交叉关注问题）？

Question

在分层应用程序中，让您在共享层中定义实体是一种好习惯吗？我想我将在所有图层中使用它们。或者它们属于业务层？

MSDN's layered application guideline将业务实体置于业务层

Layered Architecture Sample for .NET将实体置于共享层

中

可以这样吗？

• 演示文稿
• 商业
• 数据
• 共享
  • 实体

或者必须像这样

• 演示文稿
• 商业
  • 实体
• 数据
• 共享

该做什么以及为什么？

Answer 1

我通常按以下结构组织项目：

• 演示文稿（MVC应用程序）
  • 尝试尽可能减小控制器的体积。不要将任何业务逻辑放入控制器中。继承服务接口而不是具体实现。使用依赖注入。

• 业务层

  • 服务类属于此处，它们应包含所有业务逻辑
  • 我按功能将相关服务分组到文件夹中。每个服务都使用实体框架查询DB，并将结果映射到Model（a.k.a.View Models，Presentation Objects）对象中。因此，服务层不返回数据库实体，但返回POCO类。
    • 共享文件夹包含跨多个服务共享的服务（它们更像是基础架构代码，但我更喜欢将它们保留在业务/服务项目中）

• DAL数据访问层

  • 我更喜欢只使用实体框架，而不使用任何其他抽象。有些人使用存储库或实现自己的工作单元模式，但我不建议这样做。实体框架已经实现了工作单元并用linq封装了数据库选择，因此不需要更多的抽象。
  • 此图层仅包含Code First类（实体框架实体）

Answer 2

我想说这取决于这些实体是否包含业务逻辑。

从分层应用指南：

  

业务实体还验证实体中包含的数据   并封装业务逻辑以确保一致性和实现   业务规则和行为。

相比之下，Layered Architecture Solution Guidance似乎依赖于代码生成来创建实体，它们仅仅是数据容器，其中几乎没有逻辑。

Rich domain entities往往不属于共享模块，因为这意味着要承担大量您不希望每个人都拥有的行为（想象能够直接在客户端上操作业务逻辑）另一方面，相反的贫血是轻量级的，可以愉快方便地分布在各处。

Answer 3

我的方法有点不同。在数据层中，我存储了所有实体，在共享层中，我有DTO对象（域转移对象），它们是实体的精确副本，但没有实体框架控制。为了相互映射，我使用了一个流畅且易于使用的mapper（AutoMapper）。

我无法理解为什么Entity Framework不支持只使用实例的接口。