3

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

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

我可以在一个名为 Entities 的新层中创建实体并将 ObjectContext 留在 DA 中吗？效果如何。

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

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

我试图尽可能避免重复代码。让我知道这将如何工作。

谢谢

4

3 回答 3

2

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

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

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

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

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

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

它们是如何物理生成的？好吧，我要么用手写，要么用我一起破解的小工具写。我倾向于在我的 POCO中使用Structs(and )，但您也可以使用。Collectionsclasses

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

  • 这个很难（硬。
  • 一旦生成它们就不会发生太大变化 - 如果您的所有程序集都使用它们，您也不想改变，您很快就会破坏整个系统。
  • 我出于不同的原因构建了不同的 POCO，这绝对是一种人类判断。
于 2010-10-19T21:40:17.847 回答
2

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

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

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

于 2010-10-19T19:55:24.827 回答
0

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

本文清楚地解释了使用 STE 的优势。

于 2010-10-21T05:46:31.627 回答