我们即将启动我们的第一个更大的WCF项目，我们对如何正确分层应用程序以及所有模式的位置有一些担忧。
这些服务主要由内联网上的应用程序使用，其次是客户通过互联网使用。
我们的想法是以DDD和Microsoft Spain N Layer App为灵感，以这种方式对应用程序进行分层：
现在我们已经阅读了大量资料，例如，Fowler在他的“企业架构模式”一书中提到了远程外观模式和数据传输对象作为分布模式。
如果我正确理解外墙和WCF，我的远程外墙将是WCF中的服务合同。但是，Fowler有很多这些外观，每个都有自己的类（比如Album Service），但是在WCF中我只有一个服务契约和一个类（Microsoft在N层应用程序中执行，称之为IMainModuleService）？我们当然可以使用部分类“模拟”多个外墙，但如果您理解，我不觉得那是“方式”。但这是在WCF中完成的方式，还是完全忽略了Remote Facade模式？
Fowler建议你通过电汇而不是商业实体发送DTO，这对我来说听起来很合理。但是我见过的许多样本并没有这样做。你在WCF中这样做吗？
假设您在WCF中使用DTO，这些将是我们的数据合同，对吧？实现DTO，Fowler有一个使用Album Service（外观）的例子，它使用AlbumAssembler类（一个pr.DTO？）来使用业务实体组装DTO。我想这是使用来自应用程序/域层的服务来完成的？
但这些DTO在哪里组装？这是在应用层中完成的，在那里进行了一些验证，或者这个责任在哪里？我真的需要一些指导和最佳实践，希望你能给我。
这些是我们目前的一些问题，我们希望您可以指导我们。任何关于整体架构的评论也将不胜感激。我们还没有考虑过的另一个问题是如何在企业应用程序中处理WCF（使用WIF？）中的安全性的最佳实践。如果您对此有任何意见，请分享。
答案 0 :(得分：1)
然而，福勒在他们自己的班级（如专辑服务）中有很多这些门面，但在WCF我只有一个服务合同和一个班级
您可以定义多个服务合同，所有这些合同都定义了自己的服务端点。通常，一个服务合同应该提供一组定义明确的操作，就像一个类理想情况下一组公共方法一样。
Fowler建议你通过电汇而不是商业实体发送DTO，这对我来说听起来很合理。但是我见过的许多样本并没有这样做。你在WCF这样做吗？ 假设您在WCF中使用DTO，这些将是我们的数据合同，对吧？
您可以使用Datacontract和Datamember属性装饰您的业务实体，这样也可以使它们成为DTO。这是您的业务实体与数据合约之间的耦合问题。如果需要低耦合，则定义专用DTO并从业务实体复制其数据库值。