每个表一个存储库或每个function部分一个？
我使用ASP.NET MVC 2和C＃与Entity Framework 4.0来对规范化的SQL Server数据库进行编码。 我的数据库结构的一部分包含一个条目表，其中包含与包含驱动程序，汽车，引擎，机箱等的子表相关的外键。
我正在遵循Nerd Dinner教程，该教程为晚餐设置了一个公平的存储库。 我是为驾驶员做一个，为引擎做一个，为汽车做一个等等，还是做一个大的参赛作品？
这类工作的最佳做法是什么？ 我还不熟悉这种编码方法。
我猜这里没有单一的“最佳实践” – 这取决于您的编码风格和应用程序的要求。 您肯定可以为系统中的每个实体类型创建一个存储库 – 这样就可以了。
在你的情况下，我可能至少会考虑为驱动程序设置一个存储库，可能还有第二个用于汽车，引擎，底盘的存储库（因为那些在同一专业领域有点 – 它们是相互关联的，它们“属于”在一起）。
但是：当然，如果汽车，引擎和机箱的单一存储库过于膨胀，您可以考虑将其分解为三个单独的存储库。
我会尝试在存储库的数量之间找到平衡 – 尝试将逻辑上属于一起的组合在一起 – 以及这些存储库上的方法数量。 五种，十种方法都可以 – 如果您正在谈论20种，30种或50种方法，那么您的存储库可能太大而且难以处理。
这绝对是一个建筑决策，因此，它们并不是真正指导你的很多事实 – 它更像是一种“直觉”和经验之类的东西。 如果你还没有那种必要的经验 – 采用一种方法，使用它，当你完成后 – 再次以批判的眼光看待它并看看：它有什么用呢？ 怎么样没用呢？ 然后在你的下一个项目中，尝试一些其他方法，并在项目结束时质疑其有效性。 活到老，学到老！
就个人而言，我发现最好为每个表创建一个单独的存储库。
然后我创建一个services layer ，在一个类中，我将运行特定操作的所有命令（例如，将已经存在的驱动程序的汽车更改为新添加的汽车）。 如果我需要完成的操作包含多个相互关联的对象，那么我将调用服务层。
我尽我所能让我的存储库尽可能“愚蠢”，并将所有“聪明”的东西放在服务层。 额外的services层也可以帮助我避免膨胀我的控制器。
我正在为每个实体使用通用（参数化）存储库。 此存储库包含基本的CRUDfunction。 在此之上，我为每项function提供服务。 每个服务都实例化所需的存储库。 ObjectContext对所有这些都是通用的，每个请求都有一个。 这是我的存储库界面：
public interface IRepository { //Retrieves list of items in table IQueryable List(); IQueryable List(params string[] includes); //Creates from detached item void Create(T item); void Delete(int id); T Get(int id); T Get(int id, params string[] includes); void SaveChanges(); }
我也有通用的实现，这很长，但很容易实现。 您不必为每种类型创建存储库类，只需实例化Repository 。
我通常采用数据库的图形，并围绕我更大的单位或系统绘制圆圈。
这让我在商店里得到了类似“ProductSystem”，“OrderSystem”，“UserSystem”，“PaymentSystem”的东西。
如果系统变得太大，我会将它们分开。
如果系统太少我不在乎：无论如何一切都会成长。
如果某些东西以某种方式属于2个系统，我选择1并且不再改变它，即使第二天裂缝接缝错误：我知道当我想要再次改变它的那一天将到来。