我正在开发一个新项目，并一直在思考我的应用程序的结构。
规格：
关于SO处理这些（或相关）问题的问题存在无数问题。在这里和那里拾起点点滴滴，我来到这里：
一些额外的思考：
所有实体都位于DAL中，只有BLL知道。演示文稿不需要知道实体，因为服务层返回了DTO。由于Presentation使用MVVM，因此需要将DTO转换为ViewModel。
我是否正确说明实体不需要是Presentation和BLL引用的共享程序集？在我的旧项目中就是这种情况，既没有涉及WCF或WPF。实体位于共享程序集中，BLL返回这些实体，这些实体直接数据绑定到Presentation中的控件。但是这一次，使用服务层保证使用DTO进行传输，因此客户不再需要知道实体，只需要知道DTO。
额外的思考：谁负责创建DTO？它只是一种传输方式，所以我猜服务层。
Conrete问题：这是一个好方法吗？因为感觉有点像过度工程，我已经将我的数据库模型映射到实体，将这些实体映射到DTO和ViewModel，这感觉就像是很多开销。
答案 0 :(得分：1)
有趣的是，“架构”标签的“活跃”组中的这个问题旁边的问题是.NET N-Tier Architecture: What do I do about the Model objects?，并且它似乎比这一个更受关注，尽管非常相似。
无论如何，并非专门针对.Net / WCF / WPF，这一切都取决于您的目标灵活性（或您的要求）。对我来说，你正在做的事情并没有什么不妥，总的来说，恕我直言，这是最聪明的方法，因为它让你摆脱了数据存储的僵化。
请记住，如果您允许外部系统连接到您的系统（例如，通过Web API），您绝对应该不公开您的DAL。甚至BLL也应该包装在一个薄层中，以便您可以抽象传输层的特定需求（这是WCF尝试实现的，但如果您在特定传输通道上有特殊的业务逻辑，则可能还不够 - API密钥，等）。
最大的好处是能够根据所调用的服务自定义您的DTO。举个例子，看看LinkedIn的网络API。它们允许客户在任何给定时间“请求”它想要的数据并构建数据集的特定视图，以适应其需要，减少带宽使用（对于客户端不接收整个数据集的每个API服务，只需它要求的特定视图）。这是一个Web示例，但设计模式也适用于胖客户端。
关于性能，将实体转换为DTO以查看对象等肯定会产生影响。但请检查系统的性能是否首先受其他因素（数据库，内存，线程等）的约束。 DTO选项甚至可能更快，具体取决于您构建服务的方式，因为您可能通过网络发送的信息少得多。仔细设计BLL可能更重要，这样您就可以将实体带到DTO进行实体对话。这同样适用于系统中的每个其他层（服务到演示等）。