0

A question regarding the repository pattern and query object pattern. I'm using EF 4 and have generated my POCO classes from my database model using the ADO.NET POCO Entity Generator in VS 2010. The edmx file and the tt file (POCO classes) are in 2 different projects.

My repositories are domain specific, e.g DocumentRepository and UserRepository. My database model differs from my domain model in such a degree that I have implemented mappers in order to translate a domain object to one or more database tables (and vice versa). One example is that my Document domain class is modeled as 3 tables (and therefore POCO classes) in the database.

How would you implement the query object pattern when using domain objects in such a case? The way I see it I'll have to write the query object base on the POCO classes and not the domain classes? But wouldn't that break the repository pattern?

OKB
  • 715
  • 3
  • 14
  • 30
  • entity-framework 4.1 allows you to split an entity into multiple tables. This way it would not break repo pattern. – Eranga May 30 '11 at 08:56

1 Answers1

3

ORM is usually used in the way that it works directly with domain objects = it loads them from database and it persist them to database. You are doing one more abstraction step where you are using ORM entities only to fill your custom objects. Your custom objects are completely out of scope of your ORM tool and you cannot expect that ORM tool will provide you any support for queries build on top of your domain objects. You must built your own query support and translate domain queries to ORM queries inside your repositories. This is usually done by implementing Specification pattern.

Btw. in such scenario POCOs doesn't make too much sense - POCOs are for scenarios where you want to use them as domain objects).

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • I realize that my efforts to implement the repository pattern creates a somewhat complicated design since I don't want to use my POCO classes in my presentation and business layer. I feel that they don't model my domain the way they should and that's why I started to use domain classes. I can't see why the specification pattern is the way to go here, but then I haven't used it before. – OKB May 30 '11 at 09:17
  • Specification will allow you defining the query in the way you need on top of your domain model and you will translate it to EF query needed for EF in the repository. – Ladislav Mrnka May 30 '11 at 09:30
  • So then I need to write the translation logic from domain query to EF query as well.. I'm not sure that I have the time to do all this and it complicates things by far. If I use the POCO classes in the specification and write queries on them I ruin the layer boundaries right? My goal was after all to hide the data model by using domain objects. Maybe I should reconsider using the repository pattern in this project. – OKB May 30 '11 at 10:54
  • But that is the way how you created your design. Do you want custom queries with custom objects? If the answer is yes you must build "query description" = specification pattern which will be passed to the repository (= following pattern which says that user specifies queries in the declarative way) and repository must handle all the complexities. If you don't like it because it is complicated then expose POCOs from your repositories instead of custom domain objects, and use linq-to-entities directly. In UI you can use custom view models or other presentation oriented classes loaded from POCOs. – Ladislav Mrnka May 30 '11 at 11:00
  • Well, I wanted queries on top of my domain objects to make my design more flexible, but I start to regret that now:) Maybe I should write specific methods on my repositories that do exactly what I want instead of a more generic approach. It will keep things simple (but bloat the repositories). There is a lesson to be learned here I think! :-) Thank you for answering my questions, Ladislav! Keep up the good work on stackoverflow! – OKB May 30 '11 at 11:17
  • Yes that is another approach but as you mention it will make public interface of you repositories complex - you will have a method per query. It is the way how repositeries were sometimes constructed on top of stored procedures. I personaly don't like this approach. – Ladislav Mrnka May 30 '11 at 11:22
  • So true! But I struggle to see how I should implement the specification pattern on my domain objects and then translate those expressions to EF queries. I haven't done that before. Do you know any good literature on this maybe? – OKB May 30 '11 at 11:31