EF - 3 层不安全

本文关键字：不安全 EF | 更新日期: 2023-09-27 18:36:05

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

现在，对 aspx 页进行映像：

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

不好，您必须通过 CustomerRepository.Update、Insert or Delete 方法，以便我可以对所有 CRUD 操作执行一些验证。这样，所有业务逻辑都不会像我所说的那样工作。

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

它们就没有意义。

我错过了什么吗？

EF - 3 层不安全

好吧，让我们开始吧。

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> ();

然后提交。

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

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

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

相关文章：