EF -3层不安全

Question

假设一个典型的三层应用程序。在DAL中，您有一个GenericRepository，其中T表示POCO类，它包括一些方法，如插入(T entity)、删除(T entity)、更新(T entity)等等。然后，您的BLL (业务逻辑类)包含类似CustomerRepositor的内容。好吧，好吧。

现在，想象一下您的aspx页面：

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

不好，你必须传递CustomerRepository.Update，Insert或Delete方法，以便我可以对所有CRUD操作执行一些验证。通过这种方式，所有的业务逻辑都不会像我所期望的那样工作。

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

我是不是遗漏了什么？

Answer 1

好了，让我们开始吧。

var customers = BLL.CustomerRepository.GetAll();

这是上千年的一行不错的代码。在泛型和LINQ出现之前。塞鲁斯利。

如今，我希望它至少是这样的：

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

根本不需要" all“方法;)

我是不是漏掉了什么？

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

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

将会是更好的抽象。创造不是用"new“完成的，而是用

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

然后提交。

所有验证都可以在validation方法中进行检查。

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

最后，它表明，需要更多地考虑如何设计DAL接口，请停止使用完全过时的方法，并且只会导致方法爬行(因为您需要大量的方法，否则这些方法将消失在泛型+ linq表达式树中。