如果是 3 层域驱动设计的应用程序，模型应该驻留在哪里？答案

【问题标题】：Where should Model reside in case of 3-tier Domain Driven designed application?如果是 3 层域驱动设计的应用程序，模型应该驻留在哪里？
【发布时间】：2011-11-28 07:12:44
【问题描述】：

在典型的面向业务的瘦客户端应用程序（在我的例子中为 Silverlight）中，域模型应该驻留在服务器端还是客户端或两者都驻留在域驱动设计方面。我应该在客户端使用我的域实体还是 DTO？

如果我的应用程序支持“无服务器”模式，当它除了下载应用程序之外不与服务器通信时会怎样。目前我的无服务器模式对应用程序是透明的，我仍在使用相同的服务接口，但提供它们的本地实现。

【问题讨论】：

嗯，你能具体说明一下'Where'的意思吗？你说你有一个本地的服务实现。好吧，这些服务应该很自然地同时包含业务层和数据访问层（位于客户端上）。这回答了你的问题了吗？如果不是，请澄清您的疑虑。
我依赖，通常它驻留在服务器端，因为服务器端知道数据库结构并最初从数据库创建实体，但客户端应用程序也使用实体。
您有什么理由不使用 RIA 服务？毕竟它只是 WCF 之上的客户端代理生成器。当我说“只是”时，它实际上非常酷:)
@HiTech 是的，这对我们的项目来说很简单。
“瘦客户端”的定义是指服务持有领域模型的实际实现。 Thin = 薄域模型。无论如何，您都需要一些域模型，否则您的客户端代码和 UI 将难以理解 :) 但是对于“瘦客户端”，域模型的客户端副本将遵循尽可能/明智地解析业务规则和业务逻辑的服务器。

标签： c# silverlight wcf domain-driven-design dto

【解决方案1】：

嗯，他们可以在这两个地方都呆着。你可以：

1) 具有完整域的富胖客户端，并且具有通过 ODATA 或其他方式访问后端的存储库。 2）瘦客户端通过命令和DTO访问服务器，只实现一对验证 3) 以及两者的混合。

不幸的是，没有单一的响应，一个项目不是另一个。这是一个上下文问题。

如果您提供更多信息，我们可以帮助您选择。

【讨论】：

【解决方案2】：

您应该在单独的程序集中创建模型，并从客户端和服务器中引用它。
这样，您将能够轻松地从程序的两个部分访问模型，同时将其与图形和业务逻辑分开。

【讨论】：

这不起作用，因为 Silverlight 无法引用 .Net 程序集。有两种解决方案：使用 WCF RIA 服务，或者借助链接重用源代码文件。