有关分层架构中 WCF 中常见模式的问题
我们即将启动第一个较大的 WCF 项目，并且我们对如何正确地对应用程序进行分层以及所有模式的去向存在一些担忧。
这些服务将主要由 Intranet 上的应用程序使用，其次由 Internet 上的客户使用。
我们的想法是以这种方式对应用程序进行分层，其灵感来自 DDD 和微软西班牙的 N 层应用：
- 基础设施层
- 使用 EF4 (POCO) 和存储库模式
- 域层
- 到目前为止，我们这里有一些域服务
- 应用层
- 这里还什么都没有
- 分布式服务层（WCF）
- 这就是问题开始出现的地方。
- 表示层
现在我们已经阅读了大量材料，作为一个例子，Fowler 在他的《企业架构模式》一书中提到了远程外观模式和数据传输对象作为分布模式。
如果我正确理解 Facade 和 WCF，我的远程 Facade 将是 WCF 中的服务契约。然而，Fowler 有很多这些门面，每个门面都有自己的类（如相册服务），但在 WCF 中我只有一个服务契约和一个类（微软在他们的 N 层应用程序中这样做，称为 IMainModuleService）？我们当然可以使用部分类“模拟”多个外观，但如果你理解的话，我不觉得那是“方式”。但这是 WCF 中的做法吗？还是您完全忽略了远程外观模式？
Fowler 建议您通过网络发送 DTO，而不是发送业务实体，这对我来说听起来很合理。但我见过的许多样本并没有这样做。你在 WCF 中这样做吗？
假设您在 WCF 中使用 DTO，这些将是我们的数据契约，对吧？在实现 DTO 时，Fowler 有一个使用相册服务（外观）的示例，该服务使用 AlbumAssembler 类（一个 pr. DTO？）来使用业务实体组装 DTO。我想这是使用应用程序/域层的服务完成的？
但这些 DTO 是在哪里组装的呢？这是在应用程序层完成的，其中也发生一些验证，或者这个责任在哪里？我真的需要一些指导和最佳实践，希望您能给我。
这些是我们目前的一些问题，希望您能指导我们解决。对整体架构的任何评论也将不胜感激。我们还没有考虑太多的另一个问题是如何在企业应用程序中处理 WCF（使用 WIF？）安全性的最佳实践。如果您对此事有任何意见，请分享。
We're about to set off our first larger WCF project, and we're having some concerns on how to layer our application correctly and where all the patterns go.
The services will primarily be consumed by applications on the Intranet, and secondly by customers over the Internet.
Our idea was to layer the application this way, inspired by DDD and Microsoft Spain's N Layer App:
- Infrastructure layer
- Using EF4 (POCO), and the repository pattern
- Domain layer
- So far we have a few domain services here
- Application layer
- Nothing here yet
- Distributed services layer (WCF)
- This is where the questions begin to arise.
- Presentation layer
Now we have been reading lots of material, and as an example, Fowler mentions the Remote Facade pattern and Data Transfer Objects as distribution patterns in his book Patterns of Enterprise Architecture.
If I understood facades and WCF correctly, my remote facades will be the service contracts in WCF. However, Fowler has lots of these facades each of their own class (like Album Service), but in WCF I only have one service contract and one class (Microsoft does it in their N Layer App, calling it IMainModuleService)? We can of course "simulate" multiple facades using partial classes, but I don't feel like thats "the way" if you understand. But is this the way it's done in WCF, or do you ignore the Remote Facade pattern completely?
Fowler suggests that you send DTO's over the wire instead of business entities which sounds reasonable to me. But many samples that I've seen does not do this. Do you do this in WCF?
Assuming that you're using DTO's in WCF, these would be our data contracts, right? Implementing DTO's, Fowler has an example using an Album Service (the facade) which uses an AlbumAssembler class (one pr. DTO?) for assembling the DTO's using the business entities. I imagine that this is done using services from the application-/domain layer?
But where are these DTO's assembled? Is this done in the application layer where some validation occurs aswell, or where does this responsibility lie? I really need some guidance and best practices here which I hope you can give me.
These are some of our questions at the moment which we hope that you can guide us through. Any comments on the overall architecture will also be greatly appreciated. Another question that we haven't considered much yet is best practices on how to handle security in WCF (using WIF?), in enterprise applications. If you have any comments on that matter, please share them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以定义多个服务契约，所有这些契约都定义自己的服务端点。一般来说，一个服务契约应该提供一组明确定义的操作，就像一个类理想情况下具有一组有限的公共方法一样。
您可以使用 Datacontract 和 Datamember 属性来装饰您的业务实体，这样也可以使它们成为 DTO。这是业务实体和数据契约之间的耦合问题。如果您想要低耦合，您可以定义一个专用的 DTO 并从业务实体复制其数据成员值。
You can define multiple service contracts, all of which define their own service endpoint. Generally one service contract should offer a well defined set of operations, like a class has ideally a limited set of public methods.
You can decorate your business entities with the Datacontract and Datamember attributes and this way make them DTOs as well. This is a matter of coupling between your business entities and the datacontract. If you want low coupling you define a dedicated DTO and copy its datamember values from the business entities.