How to combine Web Api and MVC best in a single web app

Question

I am about to create a simple web app and I am wondering if I should use ASP.NET MVC 4 new feature Web API.

What's the best way to do this ?

I've done some researches and I found out there are two option :

Option 1

Make the Web Api my service layer and call it from the controller to read/write data, and render the view using view models and razor.

Option 2

Make the Web Api my service layer and call it directly from the view using Javascript.

I am not a big fan of Option 2 since I feel like I am neglecting the controller which will be used only for redirection between pages. Besides I prefer using razor rather than Javascript.

And If I choose Option 1 will I have to make an instance of one Web API in the controller? because this feels like I am doing something wrong.

What's the best option ? Is there any other options I haven't considered ?

And if you can give some references or books which can help me, I would appreciate it.

Thanks.

Answer 1

The whole point of Web API is to be a stateless RESTful service. There would never be an instance of it if you're doing it right. I realize this question is old and you may personally have learned this, but the answer isn't as much for you as it is an answer to a frequently-asked question.

Note that when speaking of Web API, more often than not, people are talking about ApiControllers and not basic MVC "Controllers" that take routes and turn them into Views.

So in your project, you may have some "Controllers" which do some basic view logic, but no business logic. Don't confuse that with your Service Layer which is a wrapper for your Business Logic and Persistence access.

I, and many, am of the opinion that ApiControllers shouldn't be mixed with your MVC application. Keep in mind that MVC does not mix well with Web API. As Filip W says:

Many of the concepts used by Web API and MVC, even though similar at first glance, are actually not compatible. For example, Web API attributes are System.Web.Http.Filters.Filter and MVC attributes are System.Web.Mvc.Filter - and they are not interchangeable.

Most flexible answer

So what you do is create a subdomain named api.YourWebsite.com, and build a new Web API ApiController project there. That Web API Project should do NOTHING more than instantiate and expose Business Logic via ApiControllers and Dependency Injection.

Alternative 1

Service-Oriented Architecture is all about reusability. If you want to keep your applications DRY, you should definitely fall into SOA. Though, every situation is different. If you will never ever use the same business logic in this website in any other application (desktop, android, tablet, ewPhones, etc), then you have an alternative method.

Create your Busines Logic Layer as a different Project, and access it directly from your web app. When your Javascript (Angular/Razor?) Controllers make a call, they can call into your ViewModels and/or Codebehind or something similar, which can instantiate Business Logic and directly access it. No need for services if everything is right there and won't be reused.

Alternative 2

Go ahead and put your Web API ApiControllers in the same project. But, be sure you separate them into different folders from your MVC "Controllers." Still, when your Javascript Controllers make a call, they will be making Routing calls to your website for stateless returns. Do not mix the stateless ApiControllers with your ViewModels and other MVC code.

The downside to this is a lack of SOC. Now you have Service-Layer and UI-Layer mixed, and your UI-Layer is forced to access your Business Logic Layer (DLL). What's wrong with that if Alternative 1 did it?

Well, what's wrong is that Alternative 1 was a small application with no room for growth. Anything else (The original plan, or Alternative 2 here) should have UI's that have no clue whatsoever that Business Logic (or Persistence) even exist. They should go about their doodies unawares of the backend world.

Answer 2

I usually have another layer (which can be a different project/assembly depending on the size and complexity of your application) for my business rules. You can call this business services, or whatever works on your case.

So both MVC controllers and API controllers use this layer; which keeps the application dry.

I personally prefer to only keep complex operations in my business layers, which means if I need to read something from my persistence layer to display in my views, I do it directly on the MVC controller. This is a matter of personal preference but I prefer to go the CQRS way.

So you MVC controllers are going to instantiate these business services (or they will be injected into your controllers if you are using IoC). For read operations you can choose to go straight to your persistance layer or use another read strategy.

The same will happen to your API controllers, they will use this "common" layer of services.

You don't need to instantiate your API Controllers on your MVC Controllers. Consuming your Web Api controllers via AJAX is ok if you are developing a SPA or similar.

There is no a single way to structure your application, there are just different ways and every one has more or less pain attached.

If you are considering introducing tests in your applications (and you should :)); then you should structure it in a way it is easy to test each part of it.

Just my 2 cents.