Entity Framework 4.0 中的分层架构答案

【问题标题】：Layered Architecture in Entity Framework 4.0Entity Framework 4.0 中的分层架构
【发布时间】：2011-04-27 16:35:43
【问题描述】：

嗨我正在尝试建筑师一个小项目。我计划拥有数据访问、业务服务、WcfService、UI 层。

我正在尝试使用 EF 4.0 和 MVC 2.0。我的问题是在哪里通过 EF 生成实体和 ObjectContext。我最初是在 DataAccess 中计划的。但要使实体在所有层中可用，我必须在所有层中引用 DataAccess dll（这不是一个好方法）。

我能否在一个名为 Entities 的新层中创建实体，并将 ObjectContext 留在 DA 中。效果如何。

Entity 和 POCO 的基本区别？（两者都应该由 EF 生成）。

这些实体是否默认作为 DataContract (Seralized) 提供？

我尽量避免重复代码。让我知道这将如何工作。

谢谢

【问题讨论】：

【解决方案1】：

我建议在Code Plex 上查看一个名为 NerdDinner 的“真实世界”示例应用程序和 185 页的 PDF 演练“如何编写每一行代码”。

正在运行的应用程序在这里：http://www.nerddinner.com/

NerdDinner 应该适合小型项目 - 您将节省大量复杂解决方案的开销。否则，您可以在层之间引入 DTO 对象并使用AutoMapper 来减少平凡的“逐个属性复制”代码。

【讨论】：

Nerd Dinner 不是分层架构。
@Jakub ：原来我确实有 +1 可以给！ @Praneeth：也许您需要解释“分层”的含义。如果您的意思是“人为地将应用程序拆分为多个项目/程序集以获得一些‘架构’的错觉”，那么不；它没有分层。但是，如果您的意思是“将关注点分离为不同的逻辑对象集”，那么它肯定是。的确;这是一个简单的例子。但你说你自己的网站很小。
感谢您的回复。我清楚地提到了我正在尝试做的事情，我在 sln 中有层，我们不在这里讨论分层架构，而是 EF 如何在这种架构中工作。
@Praneeth - Nerddiner 是实际上是一个分层架构。它不是分层架构。层和层之间的区别在于，层是同一物理组中的单独逻辑组（通常是一个程序集，但在 VS 网站项目等奇怪的情况下，它可以是多个程序集）。
@Mystere Man - 层通常是指物理边界，而不是组件。您可以部署由多个程序集组成的 1 层应用程序。

【解决方案2】：

业务逻辑应该与数据访问完全分离；正如您所说的那样，在数据访问中的所有层之间传递通用对象是不好的。

使用您的 POCO 在层之间传递数据，在一个非常没有依赖关系的通用程序集中定义这些（因为所有需要交换数据的项目都需要引用它。
使用接口分离业务逻辑和数据访问，该接口将定义被调用以传入和传出数据的方法 - 并且该数据将作为原始基本类型（int、string、bool 等）传递) 或 POCO（在您的公共程序集中定义）。
在您的数据访问实施中使用您想要的任何东西 - 在您的情况下是 EF。这意味着您必须将 EF 对象转换为 POCO，但这意味着您的架构是干净的。

但是我将如何创建 POCO（在代码中代）和实体一样吗？

我的工作观点是，业务逻辑是概念上“开始”的地方；说它体现了领域模型也相当准确。

POCO 是我们传递信息的方式 - 在大多数情况下，它们的设计将由业务逻辑（或领域模型）的需求驱动。对于域模型/ DDD 的思维方式，POCO 可能是该域的一部分（此时我仍然不确定这是否是一个问题）。

所以 - 它们是如何生成的（从概念上讲）取决于业务逻辑的需求；但是，如果性能是您需求的一个关键方面，您可能还会遇到一些由性能相关问题驱动的问题（例如在一个大型 DTO 中获取大量数据，而不是更多离散调用）。

它们是如何物理生成的？好吧，我要么用手写，要么用我一起破解的小工具写。我倾向于使用Structs（和Collections）作为我的POCO，但您可以使用classes。

出于以下几个原因，我没有考虑过自动生成业务逻辑或领域模型：

【讨论】：

这是一个很好的答案。但是我将如何像实体一样创建 POCO（在代码生成中）？是否有可能以及 POCO 和 ContexObject 之间的关联将如何发挥作用（就像让 EF 生成实体一样），比如 Persistence 和其他一些想法。
所以到目前为止，我们还没有 Microsoft 通过任何模板生成的 POCO。对于我的另一个问题，谁将使用这个 POCO 的 ContexObject
任何特定于物理数据访问代码的东西都不能在其他层中使用（假设您要遵守上述架构）。如果您在 EF 中引用 ContexObject，那么您将无法在基于 EF 的数据访问 (DA) 实现之外执行任何操作。在基于 EF 的 DA 中，您可以使用 POCO - 将数据从它们传递到您运行的查询中，与 ContextObjects 相对。

【解决方案3】：

嘿，我最近看了this 文章。这就是我一直在寻找的。 POCO 不能在 WCF 场景中使用。最好使用自我跟踪实体，为此我们可以使用 t4 模板进行代码生成。我对我的问题的空闲答案是自我跟踪实体。

this 文章中清楚地解释了使用 STE 的优势。

【讨论】：