我试图弄清楚如何在数据、业务和 UI 层之间共享我的实体。是否最好为所有层级引用的这些实体创建一个单独的项目？枚举和自定义异常呢？我有一些仅由 UI 项目使用的枚举，以及一些由业务使用的枚举。这是否意味着我应该有两个单独的 Enum 文件夹：一个在业务项目中，一个在 UI 中？与异常类似？到目前为止，我一直在一个单独的项目中维护实体、枚举和异常，这些项目都被所有 3 层引用。
我的业务项目有 Manager 类（如 ProductManager.cs），其中包含 List GetProducts() 和 SaveProduct(Product) 等方法。
【问题讨论】：
标签： c# .net entity-framework n-tier-architecture
我通常将枚举和自定义异常与接口定义放在一个单独的项目中。
【讨论】：
如果您需要所有层中的实体，那么使用单独的项目是 (imo) 最好的方法。
【讨论】：
如果这些实体在所有这些层中都具有语义含义，我建议将它们放在所有层都知道的单独项目/程序集中。
如果您有特定于某一层的实体，我会将它们限制在该层。因此，例如，您将不允许 UI 代码引发业务层异常，或允许业务层使用 UI 枚举。
根据您正在做的事情，将特定于层的类型保留在您保留共享类型的同一个项目/程序集中可能没有害处，但我认为将它们限制在自己的层中是一种最佳做法。
【讨论】：
你一直在做正确的事。创建一个包含所有实体的单独项目几乎总是可行的方法。如果枚举和异常与实体相关，它们也属于其中。
【讨论】：
考虑封装。 将它们放在需要它们的范围内，而不是更广泛的范围内。
如果某些内容仅在 UI 层中使用，请不要将其暴露给其他层。但是如果它是跨两三层使用的，那么在最底层定义它（例如，如果 UI 位于位于 Database 上的 Business Logic 上，那么 BL 和 UI 中使用的东西可以在 BL 中定义）。或者，如果某些内容或多或少是全球性的，请将其移至第三方共享库。
此外，首先要尽量减少对共享实体的需求：例如建议（有充分理由）避免自定义异常。它们中的大多数通常可以由带有一些额外信息的现有系统异常来表示（例如，消息中包含详细信息的 InvalidOperationException），从而最大限度地减少在任何地方处理全新类别的异常的需要 - 当然也无需决定在哪里定义自定义异常类型。
【讨论】：