实体框架和层分离

我正在尝试与Entity Framework一起工作，但遇到了有关层分离的问题。

我通常使用UI-> BLL-> DAL方法，我想知道如何在这里使用EF。

我的DAL通常是这样的

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL：

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

用户界面：

Person p = personBL.GetPerson(id)

现在的问题是：由于EF创建了我的模型和DAL，将EF包装在我自己的DAL中是一个好主意还是只是浪费时间？

如果不需要包装EF，我仍然可以将Model.esmx放置在其自己的类库中，还是将其放置在BLL中并在其中工作是可以的吗？

我真的看不出将EF包装在我自己的DAL中的原因，但是我想知道其他人在做什么。

因此，除了上述内容之外，我将省略DAL并执行以下操作：

BLL：

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

该怎么办？

c# entity-framework layers

— 汤玛士
source

Answers:

您提供的示例几乎没有分层体系结构。我知道它是有意简化的，但是：

您的表示层直接与Person实体绑定。仅在最简单的情况下这是可以的，而在尝试定义图层时绝对不能。

GetPerson方法还使用了一种非常糟糕的做法，即为每个调用创建一个新的上下文。您应该在构造函数中获取上下文，并且它将由您的IOC容器提供。

我使用的一个简单但有效的结构是：

Project.Core-包含视图模型和界面。
Project.DAL-使用我的EDMX和生成的代码。
Project.BLL-业务逻辑。
Project.Web-Web应用程序本身。

重要的是要注意：

核心不依赖任何其他解决方案。
DAL不依赖于任何其他解决方案。
Project.Web取决于Core，而不取决于DAL或BLL。
BLL取决于Core和DAL。

— 鲍里斯·扬科夫（Boris Yankov）
source

核心似乎是业务对象层。

— sq33G 2011年

这几乎也是我所使用的，但是，我将添加额外的DLL来满足接口声明。这样，您仅引用接口（并为DI 使用[url = unity.codeplex.com/]Unity[/url]之类的东西），并且可以确保没有意外引起的怪异依赖关系。

— 艾德·詹姆斯

通常，在没有EF的情况下，我会在“模型”层中创建自己的Person类，因此我拥有UI，BLL，DAL和Model，其中：UI知道BLL和Model。BLL知道DAL和模型。DLL知道模型。您还会创建自己的“视图模型”吗？为什么不使用EF生成的模型呢？（我知道这与分层体系结构背道而驰，但是实际上您切换了获取数据的方式有多少次？）

— Thomas

@Thomas包装视图模型中的东西抽象会让单元测试变得更加容易。

— sq33G 2011年

模型！=视图模型

— 鲍里斯·扬科夫

您无需将EDMX包装在任何东西中。

如果可以预见需要从EF更改为其他方法的可能性，则可能要扩展业务对象（利用局部类）以实现在单独的业务对象层中定义的接口。

然后，从您的代码中，您将只处理那些接口，而不处理具体的生成类。可能需要一些粘合代码才能将其结合在一起。使用EDMX可以成为您的DAL。

— 平方33G
source

因此，如果我不打算从EF更改为其他方法，则上面的代码可以吗？那我将只有UI和BLL（EDMX在BLL中）吗？

— Thomas

我的务实答案是肯定的。需要注意的是，如果EDMX很大并且大多数情况下是静态的，那么您实际上可能希望将EDMX放在它自己的小程序集中，这样您就不需要经常重新编译/重新分发它了。

— sq33G 2011年

嗯，关于重新编译/重新分发的要点:)

— Thomas

有两种通用的分层方法：严格分层和宽松分层。

严格分层的方法将一层中的组件限制为仅与对等方以及与直接在其下的层进行交互。

轻松的分层应用程序放松了约束，使组件可以与任何较低层的组件进行交互。

使用松弛分层可以提高效率，因为系统不必将简单的呼叫从一层转发到下一层。另一方面，使用宽松的分层不能在层之间提供相同级别的隔离，并且使得换出较低的层而不影响较高的层更加困难。

对于涉及许多软件组件的大型解决方案，通常会在相同的抽象级别拥有大量没有内聚力的组件。在这种情况下，每一层可以进一步分解为一个或多个内聚子系统。图2说明了可能的统一建模语言（UML）表示法，用于表示由多个子系统组成的层。

结论：如果不需要中间层，则将其丢失；并非所有应用程序都需要相同的方法，以某种方式仅出于分层目的而添加层将对复杂性成本和维护造成不利影响。

— 奥马尔加
source