Is there a repository for each table or one for each functional section? c# entity-framework


I am using ASP.NET MVC 2 and C# with Entity Framework 4.0 to code against a normalised SQL Server database. A part of my database structure contains a table of entries with foreign keys relating to sub-tables containing drivers, cars, engines, chassis etc.

I am following the Nerd Dinner tutorial which sets up a repository for dinners which is fair enough. Do I do one for drivers, one for engines, one for cars and so on or do I do one big one for entries?

Which is the best practise for this type of work? I am still new to this method of coding.

6/6/2010 2:42:53 PM

Accepted Answer

I guess there's really no single "best practice" for this - it depends on your coding style and the requirements for your app. You definitely could create a repository for each entity type in your system - that'll work just fine.

In your case here, I would probably at least consider having a repository for drivers, and possibly a second one for cars, engines, chassis (since those are kinda in the same area of expertise - they're interconnected, they "belong" together).

But: of course, if that single repository for cars, engine and chassis gets too bloated, you might consider breaking it up into three separate repositories.

I would try to find a balance between the number of repositories - try to group together what logically belongs together - and the number of methods on those repositories. Five, ten methods is okay - if you're talking 20, 30 or 50 methods, your repository might just be too big and unwieldy.

This is definitely an architectural decision, and as such, they're not really a lot of hard facts to guide you - it's more of a "gut feeling" and experience kind of thing. If you don't have that necessary experience yet - go with one approach, use it, and when you're done - look at it again with a critical eye and see: what worked about it? What about it didn't work? and then in your next project, try some other approach and question its validity, too, at the end of the project. Live and learn!

6/6/2010 4:34:26 PM

Popular Answer

Personally speaking, I find it best to create a separate repository for each table.

I then create a services layer where in one class I would run all the commands for a specific action (ex, change an already existing driver's car to a newly added car). The services layer is where I'll call multiple repository if an action I need done contains multiple objects that are interrelated.

I try my best to keep my repositories as "dumb" as possible and put all the "smart" stuff in the services layer. The extra services layer also helps me avoid bloating my controllers.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow