Question

I’ve project using Entity Framework 5 Code First, WebApi, ASPNET MVC 4, Repository and Unit of Work pattern, etc.

My architecture is as follows:

• One project for the POCOS
• One project with the context, Repository, Unit Of Work, etc
• One project with the contracts (IRepository, IUnitOfWork, etc)
• One WebApi project which holds ApiControllers for each entity of the model (GET, POST, PUT, DELETE).

Now, if I don’t want to use SPA (as I don’t have time right now to learn it) and I want to do something quick, What should I do? a new ASPNET MVC 4 project with Controllers inheriting from Controller rather than ApiController, and those controllers consuming the WebApi controllers?

Like this?

public ActionResult Index()
{
    return View(WebApiProj.Uow.Houses.GetAll());
}

That doesn’t seems to be quite good as it should be creating a Get pointing to the WebApi controller in the other project.

I’m thinking about this architecture, because mobile clients, web clients and any other clients would be calling the same services which sounds good.

Any advices on this architecture? Pros or cons?

Answer 1

I am not sure if what you show is possible? WebApiProj.Uow.Houses.GetAll() Is treating Houses as if it was a class with a static GetAll function on it. Houses is an instance class that needs to be instantiated per request and may/should have constructor injection concerns to handle too… GetAll would normally be an instance method.

Given you are in a situation where you are going to have multiple code clients i.e. the WebApi controllers and the MVC controllers you should consider adding a Service Layer to your project. http://martinfowler.com/eaaCatalog/serviceLayer.html.

Your Service Layer will probably take the form of a single class (if this is a small ish project but split it up if needed), it will have the Repositories and the Infrastructure code injected. You should end up with a series of CRUD and UseCase sounding method names that contain the orchestration logic between repositories, factories and unit of work classes.

public interface IMyServiceLayerClass
{
      IEnumerable<House> GetAllHouses();
      House SaveHouse(House house);
      IEnumerable<Windows> GetAllHouseWindows(int houseId);
      //etc
}

public class MyServiceLayerClass : IMyServiceLayerClass
{
     private readonly IRepository<House>  _houseRepository;
     private readonly IUnitOfWork  _unitOfWork;
     private readonly IRepositoryTypeB _repositoryTypeB; 

     Public MyServiceLayerClass(IUnitOfWork unitofwork, IRepository<House> houseRepository, IRepositoryTypeB repositoryTypeB)
     {
           //Populate the private readonly's
     }

     public IEnumerable<House> GetAllHouses()
     {
         return _houseRepository.GetAll();
     }

Your two types of controller can then accept the Service class and have very thin logic just to forward on to the service layer.

public class HomeController : Controller
{
    private readonly IMyServiceLayerClass _myServiceLayerClass;

    public HomeController(IMyServiceLayerClass myServiceLayerClass)
    {
        _myServiceLayerClass= myServiceLayerClass;
    }

    public ViewResult Index()
    {
         return View(_myServiceLayerClass.GetAllHouses());
    }

Same for the Api:

public class HouseController : ApiController
{
    private readonly IMyServiceLayerClass _myServiceLayerClass;

    public HouseController (IMyServiceLayerClass myServiceLayerClass)
    {
        _myServiceLayerClass= myServiceLayerClass;
    }

    public IEnumerable<House> Get()
    {
         return _myServiceLayerClass.GetAllHouses();
    }

This will allow you to reuse the same business logic and orchestration across the controllers abstract the logic away from your WebApi and Mvc applications.

This code could easily live in your project that defines the contracts as it is only dependent upon interfaces. Or you could add its interface into contracts too and then create another project class Domain or Service which can hold the implementation of the service class.

I would strongly suggest you leave you Controllers to do what they do best and let them handle the delegation of the UI specific elements and re-factor non UI specific logic into a reusable service layer. This would allow Unit tests for controllers to focus on testing for the correct action result and status codes etc and allow your domain logic to be tested independently.