Reputation: 639
I have been working on a project that implements a repository pattern. Basically it has the following structure:
Domain Objects <-- classes mapping database objects
Repositories implementing the IRepository or IGetOnlyRepository interface
DTO objects to communicate with the clients
I am involved in generating reports from the database. The reports are rather complex, and rely on data generated from stored procedures or execution of dynamic queries. I have noticed that so far in order to execute queries for the reports, the developers have used methods inside a given repository that execute queries against the database (using session.ExecuteQuery method of NHibernate).
However, queries executed are often combining multiple tables and for me they do not belong inside repositories. Can you suggest me a good practice as to where we can execute such queries?
Upvotes: 0
Views: 324
Reputation: 4509
My suggestion is: DO NOT use repositories in the top level of your architecture.
Your system should be split into modules. So you should have a separate 'Reporting' module, where you use direct sql instead of repositories. You might also want to create new 'flat' models in reporting module for performance purpose.
If all modules are required to use your repositories for data access, it's just like resolving different problems using one silver bullet. That just won't work!
In Domain Driven Design, there's a concept 'Bounded Context'. So your reporting module might be a separate bounded context. Different bounded contexts use different Ubiquitous Languages. Don't use one set of models across the whole system.
Upvotes: 1