最近我一直在使用MVC4，并且对View＆gt;感到非常满意。查看模型＆gt;控制器＆gt;服务＆gt;与IoC和所有的存储库堆栈。我喜欢这个。它运作良好。但是，我们正在转向公司范围的应用程序平台，该平台将满足公司内部大部分业务应用程序的需求。
基本架构目标：
我最初的想法是通过将我的服务接口应用于WCF合同并在我的IoC中注册WCF代理类来引入“企业服务层”。这将允许我重复使用我目前正在使用的相同模式，但我在实践中没有找到很多这样的例子。 this guy除外。
不可否认，我不确定这个规模的项目最佳解决方案是什么。
1）集中业务服务时需要考虑哪些因素？
2）这对交叉问题如验证，授权等有何影响？我以为我已经想到了这一点，但在各层之间放置DTO会改变这一切。
3）我对WCF很有经验，但我听到Service Stack风靡一时...... SS是否应该成为RESTful善的考虑因素？
答案 0 :(得分：1)
这家伙在这里。我无论如何都不是这方面的专家，但希望我能提供更多关于事物的背景。
根据我的帖子，使用IoC解决WCF ChanelFactory依赖关系的主要问题是客户端还需要访问服务合同。这适用于View＆gt;查看模型＆gt;控制器＆gt;服务＆gt;存储库类型体系结构，但对于共享公共API可能不太可能（或不可取）。
试图涵盖您的其他问题：
1）您的第二个问题已经提到了一些问题。除此之外还有安全性，可发现性，有效负载类型（XML，JSON等），版本控制等......这个列表还在继续。一旦集中注意力，您就会突然获得更多的管理开销。你不能在不了解后果的情况下改变合同。
2）所有横切的东西都需要在您的服务中得到满足。你不能相信来自客户的任何东西，特别是如果它们是公开的。客户可以为自己添加一些验证，但您必须确保正确锁定服务。
3）WCF是一个选项，特别是如果您的组织有很多现有的WCF。它特别有用，因为它支持许多不同的绑定类型，因此意味着您可以通过更改合同的绑定类型来随时间迁移到新的体系结构。
它非常“'企业化”，并且有一系列令人眼花缭乱的功能，可能对您的需求有些过分。
ReST目前很受欢迎。我没有使用过Service Stack，但是在Asp.Net Web Api上有很好的效果。另外，WCF can also do ReST。
答案 1 :(得分：0)
我之前已经详细解释了ServiceStack and WCF on InfoQ之间的技术和哲学差异。就API设计而言，此前面的答案显示了ServiceStack Message-based approach and WCF / WebApi remote method approach之间的差异。
ServiceStack也有Soap Support，但您今天真的不应该使用SOAP进行绿地网络服务。
ServiceStack还有一个great HTML Story可以独立运行，支持 Razor 支持，如razor.servicestack.net或Markdown Razor支持所示，如{{ 3}}
ServiceStack还可以与servicestack.net/docs/中的 ASP.NET MVC 很好地集成，它也可以利用Social Bootstrap Api。