Question

我正在开发一个MVC 3 Web应用程序，它包含大约15个代表15个DB表的实体模型类，我目前正在一个模型存储库类中执行所有业务逻辑，该类从我拥有的所有控制器类中调用。我正在一个存储库中完成所有工作： -

避免部分更新。
将所有修改（插入，更新，删除）包装到一个数据库事务中。
避免为每个模型对象定义存储库类，并创建UnitOFWork类以在所有存储库之间进行协调，我发现它会使代码复杂化并增加额外的工作量。

因此，我的方法是让一个存储库类遇到诸如性能，安全性等问题，或者我应该注意的其他问题。

Answer 1

如果需要，您可以这样做。但是，您最终可能会遇到难以处理的存储库实现。您说您想避免为每个模型对象定义一个repos类。这是我不推荐的另一个极端。通常有一个更好的中间地带。

有一本名为Domain Driven Design的书。其中一个建议是尝试使用“Aggregate Root”存储库。您可以根据这些关系将实体组织到组中，然后为每个组创建一个存储库。存储库中的主要实体称为组的“聚合根”，并且有其他实体“悬挂”它。

例如，假设您有一个具有LineItem实体集合的Order实体。您实际上只能通过订单访问订单项，因此您不需要单独的LineItemRepository。您可以查询订单，并急切或延迟加载订单项。然后，Order可以具有CustomerAccount实体的导航属性，该实体具有PaymentProfile实体的集合。同样，相同的模式 - 您只需为客户帐户创建一个存储库，而不会直接查询PaymentProfile。通过CustomerAccount查询。

此外，我从您之前的一个问题中了解到您正在使用EF。 EF为您管理交易。每次调用SaveChanges时，EF都会在事务中运行它。所以＃2并不是拥有1个巨型存储库的理由。

<强>更新

就UnitOfWork而言，通过良好的前期设计，您可以非常轻松地管理存储库中的UoW。我们的每个存储库都有一个UnitOfWork对象（基本上包装了EF DbContext）。我们的代码都没有直接构造对象。相反，我们使用我们的依赖注入/控制反转容器（Microsoft Unity）来在每次由控制器构建存储库时自动构建UoW（同样，使用依赖注入）。

通过将依赖关系生存期配置为每个请求的一个实例，我们可以确定，至少在我们的MVC项目中，每个存储库都获得相同的UoW实例（因此所有存储库都具有相同的DbContext实例）。

<register type="IUnitOfWork" mapTo="CustomDbContext">
    <lifetime type="singleton-per-http-context" />
</register>

Answer 2

为什么不实现通用存储库。看看这篇文章，希望它可以提供一些帮助

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

我可以为我拥有的所有实体类定义一个存储库类

2 个答案: