实体框架4.0中的分层架构

Question

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

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

我可以在名为Entities的新图层中创建实体，并将ObjectContext保留在DA中。效果如何。

实体与POCO之间的基本区别？ （两者都应由EF生成）。

默认情况下，这些实体是否可用作DataContract（Seralized）？

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

谢谢

Answer 1

我建议您查看一个名为NerdDinner的'真实世界'示例应用程序和185页的PDF演练'{3}}上的“每行编写方式”。

正在运行应用：Code Plex

NerdDinner应该适合一个小项目 - 你将节省更多复杂解决方案的开销。否则，您可以在层之间引入DTO对象，并使用http://www.nerddinner.com/来减少平凡的“按属性复制的属性”代码。

Answer 2

业务逻辑应与数据访问完全分离;正如您所说的那样，将公共对象放在数据访问的所有层之间传递是不好的。

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

  

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

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

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

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

它们是如何在物理上产生的？好吧，我是手工编写或使用我一起入侵的小工具编写的。我倾向于将Structs（和Collections）用于我的POCO，但您可以使用classes代替。

由于以下几个原因，我没有考虑自动神奇地从业务逻辑或域模型中生成：

• 很难。
• 一旦生成，它们不会发生太大的变化 - 如果它们被所有组合使用，你也不想这样做，你很快就会破坏整个系统。
• 我出于不同的原因建立了不同的POCO，这绝对是一种人类判断的东西。

Answer 3

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

使用STE的优势在this文章中有明确解释。