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


I am coding against a normalized SQL Server database using ASP.NET MVC 2 and C# with Entity Framework 4.0. A table of items in my database schema includes foreign keys connecting it to sub-tables comprising drivers, vehicles, engines, chassis, etc.

I am following the Nerd Dinner tutorial, which is reasonable in that it creates a repository for meals. Do I create separate ones for drivers, engines, vehicles, and so forth, or do I create a single, massive one for entries?

What is the most effective method for this kind of work? I'm still learning how to code with this approach.

6/6/2010 2:42:53 PM

Accepted Answer

There isn't really a single "best practice" for this, I suppose; it all relies on your coding approach and the demands of your app. You could certainly build a repository for each sort of object in your system; that would be acceptable.

In your situation, I would definitely think about having a repository for drivers and maybe another for vehicles, engines, and chassis (because they are sort of in the same field of knowledge - they're related, they "belong" together).

But of course, you may think about splitting up that one repository for automobiles, engines, and chassis into three other repositories if it becomes too large.

In order to combine things that logically belong together, I would aim to strike a balance between the number of repositories and the number of methods on those repositories. Five or 10 ways are OK; if you're talking about 20, 30, or 50 methods, your repository may just be too large and awkward.

There aren't many concrete data to help you make this choice since it's an architectural one; rather, you should go with your "gut feeling" and experience. If you don't yet have the requisite experience, choose one strategy and utilize it. Once you're done, go back and evaluate it critically to determine what succeeded. Why didn't it work, exactly? then in your subsequent assignment, experiment with a different strategy and consider its applicability as well at the conclusion. Never stop learning!

6/6/2010 4:34:26 PM

Popular Answer

For me, it works best to designate a different repository for each table.

I then develop aservices layer where I would execute each instruction for a particular operation (such as switching a driver's current automobile for a newly added car) in one class. If an operation I need to be performed requires the completion of numerous, related objects, I will contact multiple repositories at the services layer.

I do my best to keep my repositories as "dumb" and the services layer as "smart" as feasible. the addedservices I can prevent bloating my controllers by using layers.

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