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.
