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也可以实现为Repository。有很多方法可以创建通用存储库，这样您只有一个类，并在实例化存储库时定义实体类型：

var repository = new GenericRepository<User>();

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

有很多关于在互联网上实施存储库和工作单元模式的文章。我把它们中的一些存储在家里作为收藏夹，所以如果你有兴趣我可以在以后将它们包括在我的答案中。

是创建数据访问组件和业务组件的双重工作吗？

1 个答案: