创建数据访问组件和业务组件是否需要双重工作？

Question

我正在设计我的第一个分层应用程序，它由数据层、业务层和表示层组成。

我的业务组件（例如，Business.Components.UserComponent）当前具有以下方法：

public void Create(User entity)
{
    using (DataContext ctx = new DataContext())
    {
        ctx.Users.AddObject(entity);
        ctx.SaveChanges();
    }
}

我喜欢这种设计。但是，我在网上遇到了一些建议采用以下实现的示例：

public void Create(User entity)
{
    // Instanciate the User Data Access Component
    UserDAC dac = new UserDAC();
    dac.InsertUser(entity);
}

这将导致为所有实体创建一个数据访问组件，每个实体都包含基本方法（创建、编辑、删除...等）。

这似乎是双重工作，因为我必须使用基本方法创建数据访问组件以及仅调用数据访问组件中的方法的业务组件。

在分层应用程序中正确实现基本 CRUD 功能的最佳实践是什么？它们应该在业务组件中还是在数据访问组件中“编码”？

Answer 1

这取决于。如果您希望业务层只执行 CRUD 操作，那么您可以遵循最初的方法。如果您计划使用一些大型业务逻辑，其中业务组件将与许多实体一起使用，则第二种方法更好。

人们喜欢使用第二种方法的原因是测试和持久性的无知。如果您使用第一种方法，您的业务组件将与实体框架紧密耦合。模拟 ObjectContext 并不是一件容易的事，因此测试很困难。如果您使用第二种方法，您的业务层将独立于持久层。您可以轻松测试它，甚至可以根据需要更改持久层。但这些是您目前可能不需要的更高级的概念。您的代码需要一些额外的改进才能进行测试。

DAC 也可以作为存储库来实现。有很多方法可以创建通用存储库，以便您只有一个类，并在实例化存储库时定义实体类型：

var repository = new GenericRepository<User>();

另请注意，使用单独的数据访问层会带来新的复杂性，因为有时在多个存储库之间共享单个上下文是合理的存储库。这与所谓的工作单元模式一起出现。

互联网上有很多关于实现存储库和工作单元模式的文章。我将其中一些作为最爱保存在家里，因此如果您有兴趣，我可以将它们包含在稍后的答案中。