Question

我正在尝试使用UI，BLL和DAL构建三层架构。我正在使用Entity Framework和存储库模式。

我的问题是：实体框架生成的实体应该作为我的BLL的一部分，还是仅仅是DAL对象？

询问的原因是因为感觉我正在复制代码。例如：我有一个DAL.CatEntity，它是由Entity Framework直接从我的数据库生成的。这一切都很好，花花公子。然后我使用我的存储库（它是我的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,
        //....
    }
}

UI：

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

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

感谢。

Answer 1

最终，无论你做什么都取决于你。在实用和实用的土地上，大多数应用程序介于理想和可怕之间。

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

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

但是，我总是要小心，将业务或数据对象直接发送到UI。您应该拥有在业务和UI之间进行转换的专用UI对象。

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

Answer 2

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

Answer 3

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

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

这种方法令人惊讶地有用，但很少被描述。

实体框架DAL，BLL与存储库模式

3 个答案: