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

Question

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

MSDN的分层应用指南将业务实体置于业务层

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

可以这样吗？

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

或者必须是这样

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

该怎么做？为什么？

Answer 1

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

• 演示（MVC 应用程序）
  • 尽量让你的控制器尽可能小。 不要将任何业务逻辑放入控制器中。 依靠服务接口而不是具体的实现。 使用依赖注入。

• 业务层

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

• DAL 数据访问层

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

Answer 2

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

来自分层应用指南：

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

相比之下，分层架构解决方案指南似乎依赖代码生成来创建实体，它们只是数据容器，其中几乎没有逻辑。

富域实体往往不在共享模块中，因为这意味着携带大量您不希望每个人都拥有的行为（想象一下能够直接在客户端操作业务逻辑......）贫血的相反，它们是轻量级的，可以愉快而方便地分布在任何地方。

Answer 3

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

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