如何向 UI 组件公开服务层
我们有一个应用程序，在其中创建了一个服务层，其中包含大多数业务逻辑和实用服务（日志记录、异常、缓存等）。我们必须找到一种方法将此服务作为 API 公开给 UI 组件。以下是我们的一些要求：
- 我们希望创建多个 基于服务的组件。
- 我们需要第三方开发商 使用我们的服务来创建他们的 拥有组件或利用我们的数据。
- 为了可扩展性，我们希望有 安装在多个实例上 不同的盒子。同样还有 可能不仅仅是一个实例 相同的 UI 组件。
公开服务层的一种方法是将其托管在基于 REST 的 WCF 层下。
另一种方法是将服务托管在 ASP.Net MVC 项目的模型层中。 UI 组件将托管在它们自己的 MVC 项目中。 UI组件视图中的Javascript将直接调用服务项目的控制器。
WCF 应该是非常重量级的选择。另一方面，我不太相信 MVC 方法，因为我觉得这不是它的目的。
您能否向我推荐一种在 Microsoft 世界中公开我们的服务层的方法。
We have an application in which we have created a service layer with most of the business logic and utility services (logging, exceptions, caching etc). We have to come with a way to expose this service as an API to the UI components. Here are some of our requirements:
- We would like to create multiple
components based on the service. - We would like third party developers
to use our service to create their
own components or utilize our data. - For scalability we would like to have
a multiple instances installed on
different boxes. Similarly there
could be more than an instance of the
same UI component.
One way to expose the service layer is to host it under a REST based WCF layer.
The other way is to host the service in model layer of an ASP.Net MVC project. The UI components will be hosted in MVC projects of their own. The Javascript in the views of UI components will directly call the controllers of service project.
WCF is supposed to be very heavyweight option. On the other hand I am not too convinced with the MVC approach as I feel that this is not purpose it is meant for.
Could you please recommend me a way in Microsoft world to expose our service layer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
WCF 似乎是解决这个问题的方法。虽然 WCF 一开始（在我看来）是一头野兽，但多年来它通过更好的 HTTP 和 JSON 支持以及更少的自定义配置（尽管仍然允许您基本上修改服务的每个小方面）而被驯服。
将当前的服务层公开为 REST 服务非常简单，并且允许您的客户/您自己在任何支持 HTTP 的设备上轻松使用它。
请参阅：http://codebetter.com/ glennblock/2010/11/01/wcf-web-apis-http-your-way/
WCF seems to be the way to go here. Although WCF started out (in my oppinion) as a beast, it got tamed over the years with better HTTP and JSON support and less custom configuration (although still allowing you to modefy basicly every little aspect of your service).
Exposing your current service layer as a REST Service is a breeze and allows your customers/yourself to easily consume it on any device that supports HTTP.
See: http://codebetter.com/glennblock/2010/11/01/wcf-web-apis-http-your-way/
模型不是服务。模型是保存数据的 POCO。
您可以通过 WCF 服务公开您的服务，并让您的 ASP.NET MVC 应用程序使用它。如果您始终确定服务将与客户端应用程序在同一个机器上运行，则可以使用命名管道进行传输——那么与优点相比，WCF 的开销是最小的。
Models are not services. Models are POCOs that hold data.
You can expose your service through a WCF Service, and let your ASP.NET MVC app consume it. If you're always sure that the service will run on the same box as the client app, you can use named pipes for transport -- then the overhead of WCF is minimal, compared to the advantages.
WCF 似乎是 Microsoft 的发展方向，并且有充分的理由。 WCF 服务是这里的最佳选择，因为您提到了第三方开发支持。由于这些 Web 服务是由 WSDL 定义的，因此它们是跨平台的并且可以由非 .NET 应用程序使用。
它完美地分离了您的服务层以供任何组件使用。
WCF seems to be the direction that Microsoft is headed for this and for good reason. WCF services are the best option here because you mentioned third-party development support. Because these web services are defined by a WSDL, they are cross platform and can be consumed by non .NET applications.
It perfectly seperates your service layer to be consumed by ANY components.