在分层应用中，共享层中的实体（交叉切割关注）？

Question

在分层应用程序中，将实体定义在共享层中是一个好的做法吗？我想，我将在所有层中使用它们。还是它们属于业务层？

MSDN的分层应用指南 将业务实体放在业务层中

该 .NET的分层架构示例 将实体放在共享层中

可以这样吗？

• 演示文稿
• 业务范围
• 数据
• 共享
  • 实体

还是要这样

• 介绍
• 业务范围
  • 实体
• 数据
• 共享

该怎么做，为什么？

Answer 1

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

• 演示（MVC应用程序
  • 尽量让你的控制器小一点。不要把任何业务逻辑放到控制器中。在服务接口上中继，而不是具体实现。使用依赖注入。

• 业务层

  • 服务类属于这里，它们应该包含所有的业务逻辑。
  • i将相关的服务按特征分组到文件夹中。每个服务用实体框架查询DB，并将结果映射到Model（也就是View Models，Presentation Objects）对象中。所以服务层不返回DB实体，而是返回POCO类。
    • 共享文件夹包含了多个服务之间共享的服务（它们更像是基础架构代码，但我更喜欢把它们保存在businessservice项目内部）。

• DAL数据访问层

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

Answer 2

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

从《分层应用指南》中 。

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

与此形成鲜明对比的是 分层架构解决方案指南 似乎依靠代码生成来创建实体，它们只是数据容器，几乎没有任何逻辑。

丰富的领域实体 倾向于不在一个共享模块中，因为这意味着你不希望每个人都有大量的行为（想象一下能够在客户端直接操作业务逻辑...）。贫乏的则相反，它们是轻量级的，可能会被愉快而方便地分发到各地。

Answer 3

我的方法有一点不同。在数据层，我存储了所有的实体，在共享层，我有DTO对象（Domain Transfer Objects），它们是实体的精确拷贝，但没有实体框架控制。为了相互映射，我使用了映射器(AutoMapper)，很流畅，很容易使用。

我不明白为什么Entity Framework不支持接口，只用实例。