洋葱架构：我们应该允许在我们的领域实体中进行数据注释吗？答案

【问题标题】：Onion Architecture: Should we allow data annotations in our domain entities?洋葱架构：我们应该允许在我们的领域实体中进行数据注释吗？
【发布时间】：2015-04-10 16:48:50
【问题描述】：

我希望在我们的 ASP.NET MVC 应用程序中实现 Onion 架构。我了解将视图模型与域实体分开的必要性，但是我发现自己正在编写冗余代码。存在冗余代码，因为我的视图模型和域实体看起来完全相同，只是我的视图模型具有 [Serializable] 数据注释。我需要这些模型可序列化，因为我使用的是 ASP.NET 会话状态，其中状态服务器需要对象可序列化。

我个人认为域实体不应该是可序列化的，因为它会依赖于特定的技术。但是，如何避免冗余代码？

我应该补充一点，我的服务方法依赖于这些可序列化的数据模型。

【问题讨论】：

您始终可以考虑通过工厂模式添加服务，该模式可以序列化和反序列化您的域对象。
我在我的个人项目中使用带有 DDD 的洋葱架构（端口和适配器），并且我的视图模型很少看起来像我的域模型。或者，当我为客户做以数据库为中心的项目时，我看到他们在所有层中都使用相同的 EF 模型，因此我必须听取这导致的几十个问题。
@MickyDuncan 一个模型不适合任何重要的非 CRUD 应用程序。它迫使你将不同的用例（关注点）放在一个地方，最终你会得到一个科学怪人的怪物。随着时间的推移，这些模型以不同的方式发展，因此您希望每层/有界上下文有一个模型，以保持理智和高效。开发中的很多问题都是由于糟糕的设计和寻求最快/浅层的解决方案。

标签： c# asp.net-mvc serialization domain-driven-design onion-architecture

【解决方案1】：

我不会将 [Serializable] 称为数据注释本身，因为它是核心 .Net 平台 (mscorlib.dll) 的一部分。数据注解是指specific attributes，用于在ASP.Net或Entity Framework中进行数据校验等操作。

实体应该是[Serializable] 吗？可能不会，但我认为这个属性不像来自外部、面向 Web 或面向持久性的库的其他属性那样“掺入”您的域层。它不会将您绑定到特定的第三方框架。

整个“冗余代码”问题取决于 IMO 您正在构建的系统类型。在真正的 DDD 应用程序中，域实体和视图模型之间的重复可能不会那么明显，并且单独的表示模型的好处通常会超过成本。关于该主题的一篇好文章：Is Layering Worth The Mapping?

【讨论】：

【解决方案2】：

视图模型可以包含域实体/模型。我的域实体是部分类，并且所有（最终）都继承自序列化的基本实体。由于我在我的一些视图模型中使用我的域模型，所以我也在域模型上使用数据注释。您的域模型库不应依赖/引用其他任何东西（域驱动）。

【讨论】：

【解决方案3】：

我会避免使用任何持久性或非域相关的内容来注释我的域对象。这样一来，我的域项目就不会依赖于另一层，也不会被与域无关的东西弄得乱七八糟。虽然我们需要改变规则，但我更喜欢以不依赖持久性细节的方式来改变它们。

关键是要让图层专注于它们的目的，因为很容易混合它们并（及时）创建大泥球。

在您的情况下，我觉得您并没有真正拥有丰富的域，或者它的建模不正确。看来您只有数据结构，而您的需求是 CRUDy。

如果您确定应用程序不会演变为变得更复杂，即它只是数据结构操作，那么您可以使用一个模型将它们用于所有目的。基本上你可以偷工减料，对所有事情都使用“商业”模式。不需要抽象和其他东西。

但是，如果您认为应用程序会发展，或者它们现在是或将是业务规则和流程，即您需要根据业务感知的行为来建模，那么最好将事情保持高度解耦，即使在这个阶段他们好像是一样的。

为了更容易，您可以为您的视图模型定义一个（使用复制粘贴）并使用自动映射器将业务对象映射到视图模型之一。其他方法可能是您的查询服务/存储库/对象可以直接返回该视图模型（将查询结果映射到视图模型）

【讨论】：

+1。这本质上就是我试图向另一个面临稍微不同问题的人解释的内容there