Question

We are in a process of designing an application with approx 100 tables and complicated business logic. Windows Forms will be used on the client side and WCF services with MSSQL on the server.

Custom DTOs are used for client-server communication, business entities are not distributed.

Which variant of Entity Framework to use (and why):

• EF 4.0 EntityObjects
• EF 4.0 POCO
• EF 4.1 DbContext
• Something else

Database-first approach is a requirement.

Also, is it worth implementing a Repository pattern? It seems a bit redundant, as there is one level of abstraction in the mapping itself and another one in the use of DTOs. I’m currently leaned towards using auto-generated extendable repositories for each entity returning IQueryable, just to have a place to put common queries, but still allowing querying entity model directly from the Service Layer.

Answer 1

Which variant to use? Basically once you have custom DTO the only question is do you want to have control over entities code (their base class) and make them independent on EF? Do you want to use code first? If the answers to all questions are no then you can use EntityObjects. If you want to have entities persistence ignorant or use custom base class you should go to POCO. If you want to use code first or new DbContext API you will need EF 4.1. Some related topics:

• EF 4.1 Code-first vs Model/Database-first
• EF POCO code only VS EF POCO with Entity Data Model (this was related to CTP)
• ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator
• EF Model First or Code First Approach?

There are more things to consider when designing service layer. You should be aware of complications you will have to deal with when using EF in WCF. Your service will provide data to WinForms application and it will work with them in “detached mode”. Once user will do all changes he wants to do he will post data back to the service. But here comes the problem – you must tell EF what has changed. If you for example allow user to change order with all its order items (change quantity in items, add new items, delete some items) you must say EF exactly what has changed, what was added and what was deleted. That is easy when you work with single entity but once you allow user to change object graph (especially many-to-many relations) then it is quite tough. The most common solution is loading the whole graph and merge the state from incoming DTOs to loaded and attached graph. Other solution is using Self tracking entities instead of EntityObjects/POCOs + DTOs.

When discussing repositories I would refer you to this answer which refers many other answers discussing repositories, their possible redundancy and possible mistakes when using them just to make your code testable. Generally each layer should be added only if there is real need for the layer – due to better separation of concerns.