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

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

将业务实体置于业务层中

将实体放置在共享层中

会是这样吗

• 介绍
• 生意
• 资料
• 共享
  • 实体

还是一定是这样

• 介绍
• 生意
  • 实体
• 资料
• 共享

---

做什么以及为什么？

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

• 演示文稿（MVC应用程序）
  • 尽量使控制器小一些。不要将任何业务逻辑放入控制器中。依赖于服务接口，而不是具体的实现。使用依赖注入
• 业务层
  • 服务类属于这里，它们应该包含所有业务逻辑
  • 我按功能将相关服务分组到文件夹中。每个服务使用实体框架查询数据库，并将结果映射到模型（又称视图模型、表示对象）对象中。因此，服务层不返回DB实体，而是返回POCO类。
    • 共享文件夹包含跨多个服务共享的服务（它们更像是基础架构代码，但我更喜欢将它们保存在业务/服务项目中）
• DAL数据访问层
  • 我更喜欢只使用实体框架，而不使用任何其他抽象。有些人使用存储库或实现自己的工作单元模式，但我不建议这样做。实体框架已经实现了工作单元，并用linq封装了数据库选择，所以不需要更多的抽象
  • 此层仅包含代码优先类（实体框架实体）

---

我认为这取决于这些实体是否包含业务逻辑

根据分层应用程序指南：

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

相反，似乎依赖代码生成来创建实体，它们只是数据容器，几乎没有逻辑

---

倾向于不在共享模块中，因为这意味着要执行大量您不希望每个人都有的行为（想象一下能够直接在客户端操纵业务逻辑……）相反，贫血患者的体重较轻，可能会很快乐、方便地分布在任何地方。

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

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