分层应用程序中的共享层中的实体（横切关注）？

Question

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

MSDN's layered application guideline把业务实体在业务层

的Layered Architecture Sample for .NET放实体共享层

难道是这样吗？

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

还是必须是这样的

个
• 介绍
• 业务
  • 实体
• 数据
• 共享

做什么，为什么？

Answer 1

我平时组织项目结构如下：

• 演示（MVC应用程序）
  • 尽量保持你的控制器越小越好。不要将任何业务逻辑放入控制器中。在服务接口上继承而不是具体的实现使用依赖注入。

• 业务层

  • 服务类属于这里，他们应该包含所有的业务逻辑
  • 我组相关的服务到文件夹的功能。每个服务都使用实体框架查询数据库，并将结果映射到模型（又名视图模型，表示对象）对象中。所以服务层不返回数据库实体，但返回POCO类。
    • 共享文件夹中包含有多个服务之间的共享（他们更像是基础设施的代码，但我宁愿让他们的业务/服务项目内）

• DAL数据访问服务层

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

Answer 2

我会说这取决于如果这些实体包含业务逻辑或没有。

从分层应用指南：

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

相比之下，Layered Architecture Solution Guidance似乎依靠代码生成创建实体，它们仅仅是数据的容器很少在他们没有逻辑。

Rich domain entities倾向于不在共享模块中，因为这意味着携带大量您不希望每个人都拥有的行为（想象能够直接在客户端操纵业务逻辑......）相反，贫血是轻量级的，并且可能在各处愉快而方便地分布。

Answer 3

我的方法有点不同。在数据层中，我存储所有实体，并在共享层中拥有DTO对象（Domain Transfer Objects），它们是实体的精确副本，但没有实体框架控件。为了映射对方，我使用了流畅且易于使用的mapper（AutoMapper）。

我不明白为什么实体框架不支持接口，只使用实例。