MVC with web services

I'm working on building an application that's based on SOA. I have bunch of business services that I should make them available as components to another applications (so I'll use web services -SOAP-).

The application presentation layer is MVC.

1- Model: Contains DataBase methods (ORM is used).

2- Controller: Contains calls to the model methods as well as methods to handle simple view actions.

3- View: Contains renderin开发者_StackOverflow社区g content only.

So, can you give me a simple scenario how can I combine web service with my MVC application, my suggestion is to separate the model as web services, is that right?

I'd tackle it this way: (YMMV)

• Build a data tier assembly housing all your data access. Call it the DAL. It will contain all data access methods. This will enable re-use, but also allow for methods used by one application below. This is where your EF model can live.

• Build 2 web projects: MVC and web services. Each will implement business logic to satisfy their respective requirements. They'd reference and call into the DAL as needed for data access. As you noted, they're both presentation-tier services. One has a user interface, the other is a communication endpoint for remote web service consumers.

• Deploy both onto an application server as needed. Suggest creating 2 applications/sites in IIS - (i.e. "Web" and "WebServices"). This separation of applications ensures that one can be changed/downtimed/versioned without effecting the other.

• The MVC project/app will still have its Models, Views and Controllers as per normal. The biggest change here is that the Models would be used only for ViewModels as needed. It would contain any business logic to satisfy the UI requirements. Its controller methods would call the appropriate DAL public methods as needed.

• The web services project/app would be able to be changed independently as needed, while the data access would remain.

1) Place all your service operations behind an interface.

2) Consider using an Inversion of Control container to utilize dependency injection in your application. This allows you to mock your dependencies and unit test your controller logic more easily. Some examples are Windsor, Ninject, StructureMap.

3) Consider using strongly type view models for your views, instead of the objects that your ORM works with. You'll want to set up some mapping classes to help manage this, but a lot of the pain can be taken away by using something like AutoMapper.

Here's some good links on the subject:

• How we do MVC – View models
• ASP.NET MVC View Model Patterns

Never use web services for the sake of using web services: You should first have a problem that needs solving, and see that web services are the best solution to your problem. So depending on your need, web services can be used in a variety of different ways.

For example, since you say MVC is your presentation layer, you may want to insert web services as a layer between the Model and the Controller. Rather than invoking your model (data layer) directly, the Controller invokes your web services and provides a web-based front-end to the services that would otherwise be available via your SOAP API.

Another option is to make both your MVC front-end and the SOAP services access a common business/data logic layer, each providing their own "API" for the same back-end.

But again I emphasize: web services should not be used as solution in search of a problem. If it's not obvious to you where the web services should fit into your architecture, you are very likely better off without them.