我正在使用 ASP.NET MVC 2 和 C# 以及 Entity Framework 4.0 来针对规范化的 SQL Server 数据库进行编码。我的数据库结构的一部分包含一个条目表，其中包含与包含驱动程序、汽车、引擎、底盘等的子表相关的外键。
我正在关注 Nerd Dinner 教程，该教程为晚餐设置了一个存储库，这很公平。我是为司机做一件，为发动机做一件，为汽车做一件等等，还是为参赛做一件大事？
这种工作的最佳做法是什么？我对这种编码方法还是新手。
【问题讨论】：
标签： c# asp.net-mvc entity-framework
我想这确实没有单一的“最佳实践” - 这取决于您的编码风格和您的应用程序的要求。您绝对可以为系统中的每种实体类型创建一个存储库——这样就可以了。
在您的情况下，我可能至少会考虑为驾驶员建立一个存储库，并可能为汽车、发动机、底盘建立第二个存储库（因为它们属于同一专业领域——它们是相互关联的，它们“属于”在一起）。
但是：当然，如果汽车、发动机和底盘的单一存储库过于臃肿，您可以考虑将其拆分为三个独立的存储库。
我会尝试在存储库的数量（尝试将逻辑上属于一起的内容组合在一起）和这些存储库上的方法数量之间找到平衡。五个、十个方法都可以 - 如果您说的是 20、30 或 50 个方法，那么您的存储库可能太大且笨重。
这绝对是一个架构上的决定，因此，它们并不是很多确凿的事实来指导您 - 它更多的是一种“直觉”和体验之类的东西。如果你还没有必要的经验——采用一种方法，使用它，当你完成后——用批判的眼光再次审视它，看看：它有什么用？没用怎么办？然后在你的下一个项目中，尝试其他方法并在项目结束时质疑其有效性。生活和学习！
【讨论】：
就个人而言，我发现最好为每个表创建一个单独的存储库。
然后我创建一个services layer，在其中一个类中我将运行特定操作的所有命令（例如，将现有驾驶员的汽车更改为新添加的汽车）。如果我需要完成的操作包含多个相互关联的对象，我将在服务层调用多个存储库。
我尽我最大的努力让我的存储库尽可能“愚蠢”，并将所有“智能”的东西放在服务层中。额外的services 层还可以帮助我避免让我的控制器臃肿。
【讨论】：
我为每个实体使用通用（参数化）存储库。该存储库包含基本的 CRUD 功能。除此之外，我为每个功能提供服务。每个服务都会实例化所需的存储库。 ObjectContext 对所有这些都是通用的，并且每个请求都有一个。这是我的仓库界面：
public interface IRepository<T>
{
//Retrieves list of items in table
IQueryable<T> List();
IQueryable<T> 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<Type>。
【讨论】：
我通常会拿数据库的图表，并围绕我认为更大的单元或系统画圈。
这让我在商店中获得了类似 "ProductSystem" 、 "OrderSystem" 、 "UserSystem" 、 "PaymentSystem" 的信息。
如果系统变得太大，我将它们分开。
如果系统太少，我不在乎：无论如何，一切都会增长。
如果某样东西在某种程度上属于 2 个系统，我会选择 1 并且不再更改它，即使第二天决定接缝错误：我知道我想再次更改它的那一天会到来。
【讨论】：