3

我正在尝试使用 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。在将存储库用作我的 DLL 时，我可以只使用我的 EntityFramework 实体作为我的 BLL 的一部分吗？

谢谢。

4

3 回答 3

3

最终，无论您做什么，都取决于您。大多数应用程序介于理想和可怕之间，处于务实和实用之间。

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

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

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

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

于 2012-09-08T18:53:46.863 回答
2

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

于 2012-09-08T18:50:45.067 回答
1

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

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

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

于 2012-09-08T19:00:19.547 回答