开发者

How to expose a service layer to UI components

开发者 https://www.devze.com 2023-03-07 00:07 出处:网络
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 servi

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 开发者_JAVA技巧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.


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/


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 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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号