在 WCF 下移动 MVC 风格的服务层

Question

最近我一直在使用 MVC4，并且对带有 IoC 的 View > View Model > Controller > Service > Repository 堆栈和所有东西感到非常满意。我喜欢这个。它运作良好。但是，我们正在转向公司范围的应用程序平台，该平台将满足公司内所有业务应用程序的大部分需求。

基本架构目标：

• 面向客户的 MVC 站点
• 内部管理网站
• 向第三方导入/导出数据/等的大量预定作业
• Service Bus 位于中间以公开业务事件
• 供客户使用的公共 API

我最初的想法是通过将我的服务接口应用于 WCF 合同并在我的 IoC 中注册 WCF 代理类来引入“企业服务层”。这将允许我重用我当前使用的相同模式，但我在实践中没有找到很多这样的例子。除了this guy。

诚然，对于如此规模的项目，我不确定最佳解决方案是什么。

1) 集中业务服务时有哪些注意事项？

2) 这对验证、授权等横切关注点有何影响？我以为我已经弄清楚了，但是在层之间放置 DTO 会改变这一切。

3) 我对 WCF 很有经验，但我听说 Service Stack 风靡一时...应该考虑 SS 的 RESTful 优点吗？

Answer 1

这家伙在这里。无论如何，我都不是这方面的专家，但希望我能提供更多有关事物的背景信息。

根据我的帖子，使用 IoC 解决 WCF ChanelFactory 依赖项的主要问题是客户端还需要访问服务合同。这对于 View > View Model > Controller > Service > Repository 类型的架构来说很好，但对于共享的公共 API 来说不太可能（或不可取）。

试图回答您的其他问题：

1）您的第二个问题中已经提到了一些问题。再加上安全性、可发现性、有效负载类型（XML、JSON 等）、版本控制……等等。一旦集中，您就会突然获得更多的管理开销。您不能在不了解后果的情况下更改合同。

2) 在您的服务中需要满足所有交叉领域的需求。你不能相信来自客户的任何东西，特别是如果他们是公开的。客户可以为自己添加一些验证，但您必须确保您的服务被正确锁定。

3) WCF 是一种选择，尤其是当您的组织拥有大量现有 WCF 时。它特别有用，因为它支持许多不同的绑定类型，因此意味着您可以通过更改合约的绑定类型随着时间的推移迁移到新架构。

它非常“进取”，并且有一组令人眼花缭乱的功能，对于您需要的东西来说可能有点矫枉过正。

ReST 目前确实很流行。我没有使用过 Service Stack，但使用 Asp.Net Web Api 取得了不错的效果。顺便说一句，WCF can also do ReST.

Answer 2

我之前已经详细解释了ServiceStack and WCF on InfoQ 之间的技术和哲学差异。在 API 设计方面，这个较早的答案显示了 ServiceStack Message-based approach and WCF / WebApi remote method approach 之间的差异。

SOAP 支持

ServiceStack 也有Soap Support，但您今天真的不应该将 SOAP 用于未开发的 Web 服务。

HTML、Razor、Markdown 和 MVC

ServiceStack 还有一个great HTML Story，它可以独立运行，具有Razor 支持，如razor.servicestack.net 或Markdown Razor 支持，如servicestack.net/docs/ 所示。

ServiceStack 还与 ASP.NET MVC 很好地集成，如 Social Bootstrap Api 所示，它还能够利用 ServiceStack's quality alternative components。