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.
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!