Architecture MVVM、业务逻辑、实体、DTO'；然后把它们绑在一起

我正在做一个新项目，一直在思考我的应用程序的结构

规格：

• 多个可能的客户端（至少是一个基于WPF的桌面） 应用程序）
• 将（至少部分）公开的业务逻辑 第三方
• 数据访问和实体将使用LLBLGen Pro V3生成

关于如何处理这些（或相关）问题，有很多问题。到处捡拾零碎的东西，我来了：

• 一个单独的DAL，包括所有生成的实体
• BLL
• 在上面的一个瘦WCF服务将所述实体转换为DTO（例如使用Automapper）
• 使用MVVM的基于WPF的客户端

还有一些思考：

所有实体都位于DAL中，并且只有BLL知道。表示不需要知道实体，因为servicelayer返回了DTO。由于演示文稿使用MVVM，所以DTO确实需要转换为ViewModel

我说的实体不需要是演示文稿和BLL引用的共享程序集中的实体，对吗？这是一个既不涉及WCF也不涉及WPF的老项目的情况。实体位于共享程序集中，BLL返回这些实体，这些实体被直接数据绑定到演示文稿中的控件。不过，这一次，使用servicelayer可以保证使用DTO进行传输，因此客户端不再需要知道实体，只需要知道DTO

附加思考：谁负责创建DTO？这只是一种传输方式，所以我猜是服务层

---

问题：这是一个好方法吗？因为这感觉有点像过度工程化的东西，我已经在将我的数据库模型映射到实体，那些实体映射到DTO，那些映射到ViewModels，感觉这是一个很大的开销。

有趣的是，这个问题就在“体系结构”的“活动”组中的标签是，它似乎比这一个有更多的关注，尽管非常相似

无论如何，这并不是特别针对.Net/WCF/WPF，而是取决于您所追求的灵活性（或您的需求要求）。对我来说，你所做的没有什么错，而且总体而言，这是最聪明的方法，因为它使你从僵硬的数据存储中解放出来

请记住，如果您允许外部系统连接到您的系统（例如，通过web API），则绝对不应公开DAL。甚至BLL也应该被包装在一个薄层中，这样您就可以抽象出传输层的特定需求（这是WCF试图实现的，但如果您在特定的传输通道上有特殊的业务逻辑—API密钥等，则可能还不够）

最大的好处是能够根据所调用的服务定制DTO。举个例子，看看LinkedIn的web API。它们允许客户机在任何给定时间“请求”它想要的数据，并构建数据集的特定视图，以适应其需要，从而减少带宽使用（对于每个API服务，客户机不接收整个数据集，只接收它请求的特定视图）。这是一个web示例，但设计模式也可以应用于胖客户机

---

关于性能，将实体转换为DTO以查看对象时肯定会有影响。但首先检查系统的性能是否不受其他因素（数据库、内存、线程等）的限制。DTO选项甚至可能更快，这取决于您构建服务的方式，因为通过网络发送的信息可能要少得多。可能更重要的是仔细设计BLL，以便将实体到数据到实体的对话考虑在内。这同样适用于系统中的其他每一层（从服务到表示，等等）

也许我不应该在早上5点发布：-）我从其他一些问题中得出的结论是，有些人更喜欢使用POCO，因为他们有状态和行为。我使用LLBLGen为我生成模型。它们在生成的部分（包含所有属性和其他属性）和行为所在的部分类中被拆分。这不是POCO的基本概念吗？因此，DTO位于其之上，用作BLL的输入和输出。我一直在阅读有关贫血模型的文章，但如果您只有DTO，并且有外部部分负责行为，则情况似乎是这样。行为可以进入您的领域模型，并且可能应该（请参阅）。它不应该暴露于表示层，因为它通常不适合网络传输和表示（大量转换/验证等）。这一切都取决于您的系统，因此请针对解决方案的开发时间/（轻微）性能下降检查灵活性/松耦合参数。