Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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

share|improve this answer
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. – Charles Lambert Jan 11 '13 at 20:55
the WebApi and the mvc app sit on different boxes. – Charles Lambert Jan 11 '13 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 '13 at 21:17
Its a legitimate concern – Charles Lambert Jan 11 '13 at 21:18
Agreed. It just wasn't mentioned in your original question. Perhaps you could add it to clarify? – Eric King Jan 11 '13 at 21:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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