I have the following project structure I would like to implement. I would like to know if there are any pitfalls to structuring my code this way. It is going to be using Microsoft's WebAPI, an MVC 4 project, and Plain Old C# Objects (POCO). The explanation follows.

First off there is going to be a class library project that contains only interfaces and objects like so:

public interface IBookService {
   IEnumerable<Book> GetBooks();

public class Book {
   public int Id { get; set; }
   public string Name { get; set; }

This interface and class will be shared by the other projects. The first being the implementation project which contains:

public class BookService : IBookService {
  // implementation that pulls books from somewhere

The third project is going to be a WebAPI project that exposes IBookService as a uri, such as http://mysite/books. UPDATE: This WebAPI site will be sitting on a different machine than the MVC site.

Now here is where I'm concerned about my implementation choice. The fourth and final project is an MVC 4 application. It will reference only the interfaces and the web api (via HttpContent and friends). I would like to implement the IBookService interface in this project as well. Except in this implementation it would call the WebAPI like so.

public class MvcBookService : IBookService {
   public IEnumerable<Book> GetBooks() {
      var client = new HttpClient(); 
      client.BaseAddress = new Uri("http://mySite"); // would be pulled from config
         new MediaTypeWithQualityHeaderValue("application/json"));

      HttpResponseMessage response = client.GetAsync("books").Result; // blocking call
      if (response.IsSuccessStatusCode) {
          // blocking call
          return response.Content.ReadAsAsync<IEnumerable<Book>>().Result;
      } else {
         // handle response code
         return null;

I plan on enforcing this project structure for all WebAPI interaction within the company.

I don't for see any maintenance problems with this project layout. However many eyes always helps.

1 Answer 1


This is similar to a recent PSE question, and I'll answer yours with the same advice:

Don't bother creating a dependency between your MVC project and the WebAPI project. Put as much of your logic as is possible under the Service project/layer, and have both the WebAPI and MVC projects depend directly on it, independently.

Forcing your MVC project to depend on the WebAPI just adds another layer to the architecture you have to support, but without any clear benefit (that I can see).

  • The WebAPI project is the service layer boundry. I could have implemented it as, for example, a windows service hosting a WCF service. but we don't need any queuing, duplexing, or complex security requirements. So I went with the WebAPI. Jan 11, 2013 at 20:55
  • the WebApi and the mvc app sit on different boxes. Jan 11, 2013 at 21:02
  • Fair enough. All I was getting a is you already have a service layer boundary, the Service project. The WebAPI is a great interface for external clients, but it's usually overkill for internal apps. Unless, of course, you need a physically distributed architecture, in which case having a web service layer may be worth the extra overhead.
    – Eric King
    Jan 11, 2013 at 21:17
  • Its a legitimate concern Jan 11, 2013 at 21:18
  • Agreed. It just wasn't mentioned in your original question. Perhaps you could add it to clarify?
    – Eric King
    Jan 11, 2013 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.