3

I am used to building C# Windows/WebForms applications calling a service layer (ASMX/WCF etc) and do CRUD to DB using EF layer which is above the WCF layer.

Now, I am building an ASPNET MVC web app and plan to use WebAPI. WebAPI is responsible for interacting with EF. MY concern is, should I call the webAPI from jQUery/javascript client directly or I should go through the normal MVC controller to call the Web API. If I just go through WEBAPI from the client, then there is no need for me to use MVC at all ? What are the pros/cons ?

akjha627
  • 215
  • 2
  • 14
  • have a look at http://stackoverflow.com/questions/9778665/mvc-4-vs-wcf-web-api – Marvin Smit Nov 30 '13 at 21:54
  • 1
    browser->MVC->webapi seems like more layers than you need. Unless you're aggregating several webapis into one mvc layer (like a facade) I can't think of many reasons to put the extra work into multiple web layers like that. Of course, that assumes you're (or your team) is good at javascript--if that's not the case having the MVC layer may be a good idea. – Peter Ritchie Nov 30 '13 at 21:58

3 Answers3

3

There is bit of a jargon confusion here, MVC by itself is not UI or WebApi. Think of MVC as a methodology of how you organize/design your code/solution.

You can use jquery to call webapi directly. But where will the jquery be hosted, you would need a page for it, who would serve the page, it would be the server code. You would be do a lot more heavy lifting serving pages and those pages calling webapi.

You would go the route of webapi if you have apps on android/ios trying to interact with the backend, you would also have web pages call webapi when you want to load content async.

All this said, this is how I have organized my code: 1. Leverage MVC to serve both pages and web api. 2. Make web api and web page controllers call common underlying EF/infra code 3. Browser users use pages, apps use web apis 4. Browser pages also call web api for specific async content to load (for e.g, populating a drop down,...)

ragche
  • 443
  • 3
  • 11
2

While I think other answers are accurate, here is some other concerns you may think of.

First, your WebAPI is probably where your business are implemented. Indeed, you may already deal with:

  • Business related exception
  • Validation
  • Operations available
  • etc.

Your Api is what should not change, unless the business rule behind a certain functionnality changes too.

What I want to point out here is one thing: Keep your user interface completely independant from your API

The risk of using an MVC app with a WebApi

All the code together = mutiple reasons to change the same thing

By using an MVC app, you could be tempted to package the WebApi and the MVC app in the same solution. You would also be able to deploy all your stuff together. But doing it this way, you may end up with a big bunch of code where parts are not evolving at the same speed (i.e: user interface will change oftently, but do the Api will change every time a UI fix is need. NO. And do every changes to the API will impact the UI. No.)

All code together enables shortcuts

What I mean by that, is that if everything is package together, a developer could be tempted to call some method directly instead of calling the API that should be the only valid facade. Any shortcut taken can lead will lead to code duplication, bugs, validation error, etc. Again: do not package your MVC app with your API.

Solutions

Use a Javascript framework

AngularJS, ReactJS, EmberJS are good frameworks. (There are other, pick the one that fits your needs) But again, it will be a good choice for your architecture because you will create a clear separation between your UI app and your API app which are separated concerns. Your business logic will be well protected (WebApi), and you will be sure that your code is only call via HTTP calls, the only valid facade of your API. In other words, you make sure nobody will take shortcuts.

Use .NET MVC app in its own project

If you still want to use .NET MVC, I would suggest that you call your API via HTTP: no shortcuts. I would create a different solution and with a separated MVC project where calls to the API would be made using the HttpClient or something like RestSharp. What you want here is to avoid to bind your UI to your API code. You want to bind your UI to the contract define by the API facade (api controllers) not their implementation.

plog17
  • 832
  • 8
  • 23
0

I believe that you should call it from your MVC application as there you will have more

control over security and calling and modifying the data sent to and received from the WebAPI.

For example , you can send the ID for current logged in user to the web API, you can't do it

from JQuery.

This sample video , show you a simple steps for your scenario.

https://www.youtube.com/watch?v=bvYy1ZcUZWU

Mohammad Gabr
  • 221
  • 2
  • 5