project layout using webapi

Question

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
      client.DefaultRequestHeaders.Accept.Add(
         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.

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).