I'm a little unclear how this will work out. At first my application was broken into PartialViews, and the main Index page of each section would call a Html.RenderAction method to create each PartialView. The problem with this was that my Controller, service,
and repository classes would all get instantiated many times, running certain checks over and over, and it seemed inefficient. So I've changed the setup. My Controller creates a domain model for the entire View, and when the main Index page loads, it calls
Html.RenderPartial and passes in the part of the model that is the required model for each partial. Works great so far. Now I want to implement dependency injection and move to a repository pattern, having a dedicated service class and repository for each
View. I also want to use the Web Api for ajax calls, but I'm a little confused on how MVC and Api work in tandem.
For instance, my Index method in my XYZ Controller creates my domain model and sends the result to the View, but if I have an ApiController, would I then have two controllers for the same area in my site? Does anyone have an example of how these work together
correctly? I'd hate to "improve" my application and make it worse.
The way I work with these technologies is the following:
1) If my web application should be rendering the views (creating the html), I use MVC controllers.
2) If the client application controls the UI (i.e. mobile apps, ajax), I use Web API. This allows us to send just data (json) to the client. Web API is also optimized to support REST.
Both of these controllers should use a repository, so all the data access is done in that layer.
Personally, I feel if you're already working with an MVC site then you're better off using MVC itself for the web service. The Web Api stuff seems nice until you realize you can barely reuse any custom binders/validators/controllers from one with the other.
It's a major pain with little benefit.
Ironwil
Member
76 Points
96 Posts
Using Web Api with MVC
Nov 30, 2012 03:40 PM|LINK
I'm a little unclear how this will work out. At first my application was broken into PartialViews, and the main Index page of each section would call a Html.RenderAction method to create each PartialView. The problem with this was that my Controller, service, and repository classes would all get instantiated many times, running certain checks over and over, and it seemed inefficient. So I've changed the setup. My Controller creates a domain model for the entire View, and when the main Index page loads, it calls Html.RenderPartial and passes in the part of the model that is the required model for each partial. Works great so far. Now I want to implement dependency injection and move to a repository pattern, having a dedicated service class and repository for each View. I also want to use the Web Api for ajax calls, but I'm a little confused on how MVC and Api work in tandem.
For instance, my Index method in my XYZ Controller creates my domain model and sends the result to the View, but if I have an ApiController, would I then have two controllers for the same area in my site? Does anyone have an example of how these work together correctly? I'd hate to "improve" my application and make it worse.
ozkary
Contributor
2034 Points
303 Posts
Re: Using Web Api with MVC
Nov 30, 2012 06:32 PM|LINK
The way I work with these technologies is the following:
1) If my web application should be rendering the views (creating the html), I use MVC controllers.
2) If the client application controls the UI (i.e. mobile apps, ajax), I use Web API. This allows us to send just data (json) to the client. Web API is also optimized to support REST.
Both of these controllers should use a repository, so all the data access is done in that layer.
hope it helps
og-bit.com
rossisdead2
Participant
1313 Points
300 Posts
Re: Using Web Api with MVC
Nov 30, 2012 11:53 PM|LINK
Personally, I feel if you're already working with an MVC site then you're better off using MVC itself for the web service. The Web Api stuff seems nice until you realize you can barely reuse any custom binders/validators/controllers from one with the other. It's a major pain with little benefit.