Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Nov 10, 2012 07:15 AM by Mikesdotnetting
Nov 09, 2012 09:55 PM|LINK
I've tried to make a habbit of using the repository pattern in all of my work and find it very pleasant to work with and have everything organized.
When I want to retrieve from a single table, it's straight very forward, just call the table's entities' repository method that you're interested in.
The part that I'd like a bit of guidance on is how to bets proceed when pulling data from multiple tables.
I really don't want to contaminate my repositories by including calls to tables that don't match the repositories entity, so I generally create a "facade" which calls the repositories methods individually.
This keeps everything nice and tidy and in it's place, but I suspect the database queries are far less efficient than they could be as my repositories aren't using joins which they could.
Would it be overkill to have a separate folder perhaps called "dirty repositories", where I perform all of the joins?
If so, then the question I suppose is, how do I structure these repositories?
I don't want to have 1 giant "dirty repository" because it wouldn't really provide any separation, but at the same time, having 1 repository per table pairing (2 plus tables) would provide plenty of separation but could turn into a maintenance headache.
What are the common approaches to this issue? (Or am I being far too surgical in my approach?)
Nov 10, 2012 07:15 AM|LINK
Or am I being far too surgical in my approach?
Yes. You are already compromising your application's efficiency in an attempt to meet your understanding of a design pattern. Patterns are tools to be used to solve problems. They should not drive the way you design your application.
A repository is simply an object that generates business objects from a storage layer. So it's ok for a repository to have a reference to SqlClient, or EntityFramework, which would be unacceptable in the business logic layer or the presentation layer. It's
also ok for a repository that maps data from a SQL Server database to a business object to have the names of stored procedures or T-SQL in it too. Those procs or the T-SQL can have joins in it. EF uses Include to represent a join:
var companies = db.Companies.Include("Contacts").ToList();
//returns all companies with their List<Contact> property populated
I would expect to find the above in a CompanyRepository, and would also expect to see it's T-SQL based alternative if the data access technology was plain ADO.NET instead of EF.