0

假设一个经典的 3 层应用程序。在 DAL 中，您有一个 GenericRepository，其中 T 代表您的 POCO 类，它包括一些方法，如 Insert(T entity)、Delete(T entity)、Update(T entity) 等。然后，您的 BLL（业务逻辑类）包含类似 CustomerRepositor 的内容。好吧，所有权利。

现在，图像您的 aspx 页面：

var customers = BLL.CustomerRepository.GetAll();
customers.First().Name = "some name";

不好，您必须通过 CustomerRepository.Update、Insert 或 Delete 方法才能对所有 CRUD 操作执行一些验证。通过这种方式，所有业务逻辑都不会像我认为的那样工作。

我注意到没有人从未考虑过这一点，但我认为这是一个重要的问题。如果您可以绕过它们，那么拥有用于 CRUD 操作的业务方法是没有意义的。

我错过了什么吗？

4

1 回答 1

2

好吧，让我们开始吧。

var customers = BLL.CustomerRepository.GetAll();

这是上个千年的一段很好的代码。在泛型和 LINQ 出现之前。认真的。

这些天来，我希望它至少是这样的：

var customers = BLL.Repository<Customer>.ToList (); //IF you have to materialize

根本不需要“全部”方法；）

我错过了什么吗？

在很大程度上理解您仍在应用程序中，因此妥协是可以接受的。这不像您在这里运行应用程序之间的信任边界。其次，您应该编写一个更好的抽象。

Repository repository = BLL.GetRepository ();
var customer s repository.Entity<Customer>.ToList ();
customer[0].Name = null;
repository.ValidateU ();
repository.Commit ();

会是更好的抽象。创造不是用“新”完成的，而是用

var newCustomer = repository.Create<Customer> ();

然后提交。

可以在 Validate 方法中检查所有验证。

最后，这是关于您如何为存储库设计界面 - 如果您坚持不保留任何状态（这是某些操作的有效模式），那么这会给您带来问题。是的，您可以拥有不进行完全验证的存储库 - 完全有效。这真的取决于。您可能会感到惊讶，但我主要处理的应用程序中，出于性能原因，存储库通常甚至不会在与对象相同的事务中更新，更新是排队然后批处理的，而内存中的版本是相关的。操作。

最后，它表明，对如何设计 DAL 接口进行更多思考是有序的，请停止使用完全过时且只会导致方法蠕变的方法（因为您需要大量的方法，否则只是消失在泛型 + linq 表达式树中。

于 2012-06-03T17:55:06.447 回答