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?)
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.
stevex33
Member
356 Points
337 Posts
Repository Pattern And Retrieving Data From Multiple Tables
Nov 09, 2012 09:55 PM|LINK
Hi,
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?)
Mikesdotnett...
All-Star
154927 Points
19867 Posts
Moderator
MVP
Re: Repository Pattern And Retrieving Data From Multiple Tables
Nov 10, 2012 07:15 AM|LINK
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 populatedI 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.
Beginning ASP.NET Web Pages with WebMatrix | My Site | Twitter