SOA：WCF 和 Web 应用程序 - 通信开销
我正在研究大型企业系统架构。需要有多个移动客户端、Web UI 和外部应用程序的 API。因此，很明显我们应该实现面向服务的架构。我们将使用 WCF 作为服务层，使用 ASP.Net MVC 作为 Web 应用程序的框架。
我想知道如何实现Web应用程序和服务层之间的交互。在大多数情况下，它们将托管在同一服务器上。只有大客户才能将单独的服务器用于服务层和 Web 应用程序。从性能的角度来看，使用 http 绑定在 Web 层和服务层之间进行交互看起来确实是个坏主意。是否可以使用与 MVC 应用程序托管在同一服务器（甚至在同一 .Net 进程内）的 WCF，而无需通信开销？
I am working on large enterprise system architecture. There are requirements to have several mobile clients, web UI and API for external applications. So, it is obvious that we should implement Service-Oriented Architecture. We will use WCF as service layer and ASP.Net MVC as framework for web application.
I am wondering how to implement interaction between web application and service layer. For most cases they will be hosted on the same server. Only large customers could use separate servers for service layer and web application. Usage of http binding to interact between web and service layer looks like really bad idea from the performance point of view. Is it possible to use WCF, hosted on the same server (or even inside the same .Net process) as MVC application without communication overhead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以尝试进程间通信绑定，它被认为是WCF 支持的最安全（不接受来自另一台计算机的调用）和最快（比 TCP 更轻）的绑定。
You can try interprocess communication binding which is considered to be the most secure (doesn't accept calls from another machine) and the most fastest (lighter than TCP) binding that WCF supports.
如果您与 WCF 通信，总会有开销。因此，我认为更合适的问题是该开销是否可以处理，或者是否需要通过其他方式减轻它。
如果您的 WCF 服务正在执行逻辑和/或为移动客户端的数据层和外部应用程序的 API 调用提供接口，那么该逻辑是否不能移动到该服务使用的通用 API，并且如果在应用程序内部运行对于您的组织（即Web应用程序）来说，它可以使用相同的API层来避免服务吗？这可能就是我的处理方式。还有一层，但该层可以由 WCF 使用以通过这种方式公开，或者直接由 ASP.NET 应用程序（或任何有权访问资源的 .NET 应用程序）使用。
If you are communicating with WCF there will always be overhead. So I would think a more appropriate question is whether or not that overhead is OK to deal with or if you need to mitigate it in other means.
If your WCF service is executing logic and/or providing the interface to the data layer for mobile clients and API calls for external applications, can't that logic be moved to a common API that the service uses and, if run on an application internal to your organization (i.e. the web application) it can use the same API layer to avoid the service? That's likely how I would approach it. One more layer but that layer can be consumed by the WCF for exposing that way, or directly by the ASP.NET application (or any .NET application that has access to the resources).