Один репозиторий на таблицу или один на функциональный раздел?
==============================================================

 Я использую ASP.NET MVC 2 и C # с Entity Framework 4.0 для кодирования нормализованной базы данных SQL Server. Часть моей структуры базы данных содержит таблицу записей с внешними ключами, относящимися к вложенным таблицам с драйверами, автомобилями, двигателями, ходовой частью и т. Д. 

 Я следую учебному пособию Nerd Dinner, в котором настраивается хранилище для ужинов, и это достаточно справедливо. Я делаю один для водителей, один для двигателей, один для автомобилей и так далее, или я делаю один большой для записей? 

 Какова лучшая практика для этого вида работы? Я все еще новичок в этом методе кодирования. 

 Я думаю, что на самом деле нет единой «лучшей практики» для этого - это зависит от вашего стиля кодирования и требований для вашего приложения. Вы определенно можете создать репозиторий для каждого типа сущностей в вашей системе - это будет прекрасно работать. 

 В вашем случае здесь, я бы, по крайней мере, рассмотрел бы наличие хранилища для водителей, и, возможно, второго хранилища для автомобилей, двигателей, шасси (поскольку это своего рода область знаний - они взаимосвязаны, они «связаны» вместе ). 

 Но: конечно, если этот единственный репозиторий для автомобилей, двигателя и шасси становится слишком раздутым, вы можете разбить его на три отдельных репозитория. 

 Я бы попытался найти баланс между количеством репозиториев - попытаться сгруппировать вместе то, что логически принадлежит друг другу - и количеством методов в этих репозиториях. Пять, десять методов - это нормально - если вы говорите о 20, 30 или 50 методах, ваш репозиторий может быть слишком большим и громоздким. 

 Это определенно архитектурное решение, и, как таковое, на самом деле это не так много неопровержимых фактов, которые могут вас направить - это скорее "внутреннее чувство" и опыт такого рода. Если у вас еще нет этого необходимого опыта - используйте один подход, используйте его, и когда вы закончите - посмотрите на него снова критическим взглядом и посмотрите: что с этим сработало? Что с этим не сработало? а затем в вашем следующем проекте, попробуйте другой подход и поставьте под сомнение его обоснованность в конце проекта. Живи и учись!