0

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

基本架构目标：

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

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

诚然，我不确定对于这种规模的项目来说，最好的解决方案是什么。

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

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

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

4

2 回答 2

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 也可以做 ReST。

于 2013-05-23T08:09:00.430 回答
0

我之前在 InfoQ 上详细解释了 ServiceStack 和 WCF之间的技术和哲学差异。在 API 设计方面，这个较早的答案显示了ServiceStack 基于消息的方法和 WCF / WebApi 远程方法方法之间的区别。

SOAP 支持

ServiceStack 也有Soap 支持，但您现在真的不应该将 SOAP 用于未开发的 Web 服务。

HTML、Razor、Markdown 和 MVC

ServiceStack 还有一个很棒的 HTML 故事，它可以在razor.servicestack.net中看到的Razor支持或在servicestack.net/docs/中看到的Markdown Razor支持下独立运行。

ServiceStack 还与ASP.NET MVC很好地集成，如Social Bootstrap Api所示，它还能够利用ServiceStack 的优质替代组件。

于 2013-05-23T14:00:12.600 回答