1

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

我的业务组件（例如，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 功能的最佳实践是什么？它们应该在业务组件或数据访问组件中“编码”吗？

4

1 回答 1

1

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

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

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

var repository = new GenericRepository<User>();

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

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

于 2010-09-03T08:13:44.867 回答