Understanding the new Web API approach

Question

I’m aware that not everyone uses a thorough architecture when developing an MVC application but let’s assume I have the following architecture:

App.Core --> Class Library (POCO or Domain objects)
App.Data --> Class Library (Repository and Entity Framework)
App.Service --> Class Library (Service layer with all business logic)
App.Web --> asp.net MVC 3.0 project

---

App.Data --> Has a reference to App.Core
App.Service --> Has a reference to App.Core and App.Data
App.Web --> Has a reference to App.Core and App.Service

Inside our MVC application we try to follows this approach:

• Inside our Controller (within a method), we instantiate a ViewModel.
• We fill that ViewModel calling methods from our App.Service Layer
• Once the ViewModel is filled, we return it to the View (so the view is now strongly typed).

This occurs 99.9% of the time. It is clean, we like it and it leverages itself pretty well..etc!

Now my question is the following:

If we decide to move our application to MVC 4.0 and start using the new Web API approach, I’m not sure I fully understand where (or how) it would fit in our current architecture?

Keep in mind, that we are open to change this around!

Should we create a new App.WebAPI layer that sits between the App.Service and App.Web? This means inside our Controllers, we would no longer need to call the App.Service directly but instead the new App.WebAPI layer?

Or, leave the Web API inside the App.Web layer and make the Controllers call the other APIControllers which in turn would call the App.Service layer?

Not sure if I make any sense here…but please feel free to suggest anything as I’m curious on different inputs.

Thanks

Answer 1

There are a couple of cases to consider:

Do you want to make this Web API serve as service layer and data access for your MVC application? If, yes, then you should completely remove all references of App.Service from the ASP.NET MVC project and have it query the Web API instead to fetch the data. In this case the Web API sits between your ASP.NET MVC application and the data access. It is the Web API that talks to the service layer and exposes it over the HTTP protocol.

Or do you want to provide an additional API for your web site that can be used by other clients (other than web browsers)? In this case the ASP.NET MVC application and the Web API sit on the same layer. Both query your Service layer to fill view models, it's just that in the case of the MVC application you are passing those view models to views which in turn convert them to HTML whereas in the Web API layer you probably use slightly different view models but which are still populated from your service layer and are passed to the client used the corresponding serialization mechanism (JSON, XML, ...)

Answer 2

I know this is late but I was actually looking for the same advice and I found this post.

Wouldn't having "both the MVC and Web API sit within the same layer" mean more maintenance work on the code, or maybe duplication of code? isn't the mvc web considered as a browser client? .. to me it makes sense to have the WebAPI your only layer to everyone else and in turn it would call your service layer for processing.

What is the benefit of leaving both the Web API and the MVC talking directly to the service layer? Can't the web API be the wrapper around the service layer?