实体框架4.1的生成器的困惑

我正在评估一个项目的实体框架与传统数据库。该数据库设计得非常好，并且已经决定使用数据库优先方法。该应用程序将基于WinForms，但我希望提前计划并考虑ASP.Net以及它可能会在某个时间点被管理请求，我想重用DAL。实体框架4.1的生成器的困惑

现在，我的理解是实体框架提供了多种方式为实体对象中产生：从EntityObject

POCO（ObjectContext中）

POCO（的DbContext）

自我衍生

对象跟踪实体（STE）

我一直在试图比较这三种方法，直到目前为止。

EntityObject T4模板是其中最富有的。例如，它将来自实体模型的注释放置在每个类的顶部和实体的每个属性的XMLDoc注释中，这在代码可维护性方面相当不错并且有用。没有其他的生成器支持这种开箱即使（虽然我知道可以修改T4模板，但它显然需要一些工作）。另一方面，DbContext API更好一些。

EntityObject派生类型提供了一个事件，您可以在实体属性更改时挂钩，这对实现业务逻辑很有用。

我知道POCO对此更自然，但是T4生成器会在每次模型更改时覆盖我所做的所有更改。当然，生成的POCO是部分类，但据我所知，不可能覆盖已经在部分类中定义的属性，所以我不确定在它们中实现业务逻辑是如何完成的？

许多人似乎讨厌EntityObject派生类，更喜欢使用POCO方法，但它似乎损失了很多EntityObjects开箱即用的功能， POCO路线。考虑到对POCO对象的普遍偏好，我可能会误解某些东西，因此我的问题。

最后，哪种生成器最适合ASP.Net环境？我担心我的实体更改会停止跟踪？自我跟踪实体在这种情况下更有用，还是他们只对Web服务有价值（我可能不会使用）？

非常感谢提前。

来源

2011-10-11 Kharlos Dominguez

如果你想使用EF 4.1，你的选项只有DbContext Generator。所有其他生成器（POCO，EntityObject和STE）都用于ObejctContext API（EF 4.0）。我描述了发电机here之间的差异。

在你的情况下，EntityObject生成器可用于WinForms，但对于ASP.NET解决方案而言，由于ASP.NET应用程序处于分离状态，所以POCO更好，这样会很麻烦 - 无论如何，您将不得不处理ASP.NET中的更改跟踪。

STE的目的描述为here但它们在WinForm中并不是非常有用，您可以直接使用附加实体，或者在视图状态请求之间使用demands to store them的ASP.NET。

要直接放入实体的任何业务逻辑都必须在T4生成器中编码，否则它将在每代生成后被覆盖。您提到的基于EntityObject的每个功能都可以在POCO/DbContext生成器中实现。

来源

2011-10-11 12:20:38

谢谢。这很有帮助。通过“你想直接放入实体的任何业务逻辑必须在T4生成器中编码”，你的意思是我需要修改T4模板，以便生成类似于EntityObjects的On [Property] Changed的事件？我对T4做了一些改变，我不能说这是一种有趣的体验。考虑到这一点，我很惊讶没有看到更多的EF T4脚本，但只有MS-ones。另外，我担心这些事件可能不会在ASP.Net环境中引发，他们会（当数据被发回服务器时）吗？ –

“你想直接放入实体的任何业务逻辑必须在T4生成器中编码，否则它将在每一代之后被覆盖”<----这是不正确的。您需要将业务逻辑放在一个**分开的**部分类文件中，并且它将保留而没有任何问题。上面的所有生成器都已经生成了部分类。 – Bobson

@Bobson：你看过这个问题吗？我们正在讨论生成属性中的其他逻辑。仍然存在部分课程或部分方法不起作用的情况。 –

实体框架4.1的生成器的困惑

回答

相关问题