具有存储库模式的实体框架 DAL、BLL

Question

我正在尝试使用 UI、BLL 和 DAL 构建三层架构。我正在使用带有存储库模式的实体框架。

我的问题是：实体框架生成的实体是否应该充当我的 BLL 的一部分，还是这些只是 DAL 对象？

询问的原因是因为感觉就像我在复制代码。例如：我有一个由实体框架直接从我的数据库生成的 DAL.CatEntity。这一切都很好，花花公子。然后我使用我的存储库（它是我的 DAL 的一部分）将数据提取到 DAL.CatEntity 中。然后我在我的 BLL 中使用这个 DAL.CatEntity，提取它的所有数据，并将其转换为 BLL.Cat。然后我在我的 UI 层中使用这个 BLL.Cat。

下面是一些超级简化的代码。

BLL

public Cat GetCat(string catName){
    CatEntityRepository _repository = new CatEntityRepository;
    Cat cat = null;
    CatEntity catEntity = _repository.GetSingleCat();
    cat = ConvertToCat(catEntity);
    return cat;
}

private Cat ConvertToCat(CatEntity entity){
    return new Cat(){
        Name = entity.Name,
        Color = entity.Color,
        //....
    }
}

用户界面：

public ActionResult method(){
    Cat cat = BLL.GetCat();
    //......
}

似乎没有必要同时拥有 Cat 和 CatEntity。我可以只使用我的 EntityFramework 实体作为我的 BLL 的一部分，而将存储库用作我的 DLL 吗？

谢谢。

Answer 1

最终，无论您做什么，都取决于您自己。大多数应用都介于理想和糟糕之间，处于务实和实用之间。

您需要做的是查看应用的复杂性。它越复杂，它就越能从高度分离中受益。通常，应用程序的简单性并不能证明创建清晰图层所需的大量工作是合理的。

话虽如此，在我看来，在大量中小型复杂应用程序中，您可以有效地将您的实体视为业务对象。特别是，如果您将实体 POCO 和业务层的一部分，然后在您的 EF DAL 中使用这些实体，它会非常有效。

不过，我始终会提醒您，将业务或数据对象直接发送到 UI。您应该拥有在业务和 UI 之间转换的专用 UI​​ 对象。

我认为，当您可能会更改数据访问方法时，将业务与数据保持高度分离是最有意义的。例如，如果您认为可以更改为 Web 服务来获取数据，而不是直接使用 EF。此外，强大的关注点分离对单元测试有很大帮助。

Answer 2

如果您觉得自己在重复代码，那么您可能不需要服务层，并且您的 EF 实体可以充当业务模型。不需要业务层的简单 CRUD 应用程序通常就是这种情况。

Answer 3

另一种方法不是在两种类型的对象之间进行转换，而是从您的域实体创建接口并根据接口对您的存储库进行编码。

这样你可以同时烤两个蛋糕。您没有将数据层实体转换为 bll 实体，而且您仍然没有弄乱层（从某种意义上说，您的存储库不适用于具体的数据层类型）。

这种方法非常有用，但很少被描述。