带有ASP.NET Web Api建议的SOA风格体系结构

你能给我一些内置在WebAPI中的面向服务系统的例子吗？ 目前我正在考虑两种方法：

• 第一个是简单而直接的——将每个服务放在自己的Web应用程序中，彼此独立地托管在IIS中。我不喜欢它有一些原因：每个开发人员都必须自己创建Web Api项目并部署在IIS上，没有集中的Api发现，没有集中的安全机制等等

• 我认为第二个更好，但也很复杂——只有一个服务端点，我称之为网关，所有的服务调用都通过这个端点，并且在特定文件夹中有“插件”式的系统称之为“插件文件夹””，每个新服务将作为一组dll部署在此文件夹中（没有自己的服务终结点），并最终使用Web Api的

  IAssemblyResolver

  从此文件夹读取所有控制器（当然，对于不同的服务/项目）

如果我选择第二种方法，我有以下优点： 我团队中的每个开发人员都可以在不接触WebApi的情况下“发布”自己的服务，只需复制“插件文件夹”中项目的dll-s。 在本例中，路由和Api发现也非常简单，示例路由-

{Application/ServiceName}/{version}/{controller}/{action}/{id}

。我对系统等进行集中安全控制

任何建议或样品和教程将不胜感激

---

我知道SOA是独立于平台和技术的，但我没有想到更好的标题。

将服务作为独立的web应用程序托管的优点是，它们可以独立扩展并处于不同的发布周期。

---

但是，如果您向服务发出ajax请求，则需要考虑跨域问题。如果它们单独托管，它们将位于不同的域上，这意味着您必须执行类似CORS、JSONP或反向代理的操作，以允许来自浏览器的ajax请求

您不会在web上找到太多使用ASP.NET web API描述SOA的文章，我喜欢使用ASP.NET web API。也不要沉迷于WebAPI和WCF之间的比较（WCF的REST方面可能是个例外，但在这种情况下使用WebAPI又何必麻烦呢）。关于WCF，ASP.NET核心正在进行一次很好的讨论。随时关注未来的.NET版本和WCF实现的功能，无论它是如何营销的

我认为您应该问问自己是否希望/需要在SOA环境中托管服务。大型公司，如保险公司，共享API并在防火墙后共享，通常会使用SOA。如果不需要代理来调用应用程序服务器上的服务，则可能不需要复杂的体系结构。在这种情况下，ASP.NET Web API可能是一个完美的解决方案。如果您将在一个典型的SOA环境中进行开发，我现在推荐WCF和.NET 4.6.2，以及将来的.NET版本来支持WCF