MVVM、DDD和WPF分层应用程序项目结构指南
我正试图在VS中设置我的应用程序的结构，我希望“尝试”并在将来将其证明到一个合理的水平。这个应用程序将是一个WPF重写一个旧的Winform应用程序，没有遵循任何约定。没有层、层、首字母缩写等.
这是一个相当大的企业级应用程序。我计划使用Linq到SQL，因为我的DB是，而且很可能永远是MS。此外，我有一个现有的技能集与它。
我想尽可能地遵循MVVM和DDD，但是在合并这些应用程序时，我对我的应用程序的结构感到困惑。让我用一些例子来说明一下。
当我遵循MVVM时，我的文件夹结构可能如下所示：
Views
Models
ViewModels
Helpers但是，这如何适合于一种简单的DDD分层方法，在这种方法中，我的项目结构可能类似于：
MyApp.UI
MyApp.Domain
MyApp.Data我是将Models放在域层中，还是有3个版本的Person？这就引出了另一个问题:我将把我的存储库和DB对象的映射放在什么地方？我会假设数据..。
我得到的Views会进入UI，但ViewModels也会吗？
最后，我将把业务逻辑嵌入到哪里？
我在CodePlex，DDD实例上发现了以下内容，虽然这对网络应用程序有一定的帮助，但这可能并不重要，而且我的无知正一闪而过。
不要误解我的意思，我知道我可以有很多文件夹，我想怎么称呼它们都行。我正试图弄清楚把东西放在哪里，这样才能达到规模，而不是那些地方的必然名称。
我问题的核心可能是这样的。
我有由tblPerson生成的*.dbml对象。这是显而易见的，并属于我的“数据”层。
现在我会有Model，DTO，Domain，或者任何在单独层(项目？)中被调用的东西。叫Person。我需要一个Mapper，Person到tblPerson，我不知道该放在哪里。
然后，我将有一个ViewModel，比方说，EditPerson，它有自己的属性，从Person中提取，但也可能更多。
最后，我会有一个观点，被绑定到那个ViewModel..。
要明确的是，这一段充满了我的假设和猜测，我希望有人能帮我澄清问题，或者提供一些见解，这样从现在起的6个月到一年后，我不会比我需要的更多地踢自己。
回答 3
Software Engineering用户
发布于 2012-08-02 19:59:59
MVVM是一种UI模式，用于客户端。
DDD中用于客户端的域部分可能是模型的一部分
视图和ViewModel仅为客户端。
我将存储库放入(或接近)模型中，因为它们将模型同步到后端。
是的，很多时候，这将导致不同名称空间中的多个Person类。它们一开始可能非常相似，但经过几次迭代或发布后可能会有很大的不同。
编辑
澄清存储库部分，更好地解释业务逻辑的定位
如果您正在创建一个包含单独客户端和服务器端/后端存储库的系统，则可以在客户机和服务器中使用。在客户端提供一个抽象的服务器(S)和在服务器中提供其他服务器和数据源的抽象。这只是一种模式。
至于业务规则:如果您在客户端使用这些规则，请确保在服务器中也执行这些规则。永远不要相信客户。客户端中的业务规则允许快速的输入验证，并防止往返到服务器。
我确实认为DDD属于服务器端，并且“泄漏”给客户端。
Software Engineering用户
发布于 2012-08-03 03:16:02
您在为WPF应用程序选择MVVM设计模式方面有正确的方向。
Do I put the Models in the Domain layer?是的，您的模型可以放置在域中。
Where would I put my Repository and mappings of DB Object to Domain Object?您的存储库可以放置在放置域的层中。您的映射对象(也称为DTOs域传输对象)应该放在您的服务层中，您可以使用强大的映射工具AutoMapper轻松地将您的域对象映射到DTO。
ViewModels also?您的ViewModels应该放在客户端(层)上。您可以根据视图从一个或多个DTO构造视图模型。
关于DDD，我建议阅读这方面的内容，并向您说明确实需要有域驱动的设计模式。下面是关于95%的软件应用程序属于“不太适合使用DDD”的类别。的讨论
编辑:参考资料已经添加在上面，谢谢您的@Den！
Software Engineering用户
发布于 2012-08-03 12:17:38
在我们深入到哪里之前，让我们先谈谈每一层应该做什么。
MVVM的卖点是视图和视图模型之间的绑定.这里的目标是消除视图中的逻辑。
与视图一样，模型应该非常轻量级，只用于访问视图模型操作所必需的信息(数据)。该模型可以混合对不同数据源的访问，但它不应该具有业务逻辑。在大多数情况下，您只有一个数据存储需要访问。在某些情况下，您没有这样做。如果没有，则应该使用模型来模糊VM中数据的来源。
MVVM的一个隐含要点是，数据已经被存储，并且您的项目不负责维护其组织。有些项目足够幸运，能够摆脱这种假设，我从事过的大多数项目都没有那么幸运。可以说，数据是我们必须面对的另一个层。
我会像这样布置我的项目：
project.Views
project.ViewModel
project.Model
project.DataStructs这一层可以根据需要添加：
project.Helpers我将帮助程序从堆栈的其余部分分离开来，这样它就不会被混淆为应用程序堆栈的一个层。
免责声明:我不是一个DDD专家，但我理解一般的要点，并看到了方法的价值。
您的域将是您正在考虑的问题集。
域模型将主要对应于您创建的ViewModels；视图中的一点点；模型/ DataStructs中的一小块。
那怎么解决呢？
如果您有能力更改现有的数据结构，那么您创建的新结构应该与您试图解决的问题相关联。有客户对象吗？那么您应该有一个/一些与客户相关的表。有发票还是产品？应该创建映射到这些业务对象的相同的故事表和结构。
域将通过您的ViewModel对象和这些对象的视图来表示。如果您需要编辑客户记录，那么您将有一个VM来处理该任务。
关于你们的问题：
- 不要试图将DDD覆盖到MVVM上。只是不管用。DDD不是布局模式，它是查看整体问题的一种方法。
- 存储库和映射将酌情驻留在project.Data或project.Model中。
- 没有一个名为UI的层，除非这是您想要调用的project.Views。
- 业务逻辑将进入视图模型。
https://softwareengineering.stackexchange.com/questions/159283
复制相似问题
腾讯云开发者
