I have to create two different projects with the Entity Framework:

  • Web API Services
  • UI and Business Logic (MVC).

Both the projects have to work with same POCO entities. I see two alternatives and would like to know the pros and cons of each, and if one of the two to be recommended as best option:

  1. Make a different class library for the complete entity model and take its reference in both the projects?
  2. Create the class library just for POCO entities, take its reference in both the projects and use code first approach in services project (creating the context class) for database access?

Also would like to know to best structure my projects when I have three different servers, one for the web services, one for the UI and one for the database. On the other hand, if I have to follow database first approach, how do I deal with such situation?

  • are you implying that BOTH projects talk to the database? – Ewan Aug 31 '17 at 8:41

I'm not sure that your envisaged project architecture is optimal.

The web API should expose services that provide access to the domain objects together with the business logic. This service layer would use the entity framework for managing database access.

The presentation layer should offers UI but should not mix-up into the business logic, nor access the entities directly. It should access the entities and business logic only via the web services. A dumb data transfer object could be used to transfer data between the service layer and the UI.

This architecture would avoid the tight coupling that you would have using a shared library (whatever the alternative you have), where every change might impact all the other components. It would furthermore ensure that the UI level does UI only and does not manage in a hidden way some business logic that was forgotten in the service layer.

Finally this alternative architecture would allow you full flexibility for distributing the layers: you could have all on one server, or have the the presentation layer (UI but using MVP rather than MVC) on one server, the domain logic with the database on another, ore even have every layer on its own server.

P.S: in my opinion, the POCO issue becomes irrelevant with alternative architecture

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.