EF POCO代码只有VS EF POCO与实体数据模型 [英] EF POCO code only VS EF POCO with Entity Data Model

问题描述

将域对象完全从任何种类的持久性代码中分离出来的能力使系统更加可扩展和可维护。当业务逻辑可以与存储代码分开测试时，测试变得更加容易。使用POCO与实体框架（EF）绝对是正确的方向的一步：）

有两种类型的使用poco与EF
1使用实体设计器
2.仅使用代码

哪一种是EF poco代码或EF Poco使用实体数据模型设计器的最佳方法？

谢谢

解决方案

这只是一个选择。

EFv4设计师

优点：

• 您有设计师支持和T4模板，将为您生成实体= RAD。


• 您有非常大的功能集，包括支持视图，存储过程映射和一些自定义模型定义的对象，如QueryView或Model定义的函数。


• 在需要时支持其他EF类型（自我跟踪实体，实体对象）。

缺点：

• 设计师不是很好的工具模型（50多个表）


• 设计师不支持所有功能 - 您必须以XML格式访问EDMX


• EDMX XML结构可能是最复杂的并且很难理解所有可用的.NET ORM工具之间的描述


• 与设计师共享环境工作只是一个痛苦 - 最好在EDMX上使用排他锁


• 编辑：我忘记了我非常受欢迎的缺点。 Designer将所有映射数据存储在EDMX中，以及自己关于图中定位实体的数据。即使这样愚蠢的动作，如缩放图，将从源代码控制中查看EDMX文件。

EF代码第一

优点：

• 能够定义代码中的所有内容


• 基于属性的映射和Fluent API


• 一些非常好的API功能 - 约定，本地等。


• 我认为这个API不那么复杂和更容易使用

缺点：

• 还没有最终发布。目前的版本只是社区技术预览5。


• 由于该API可能会在最终版本中更改。


• 您必须自己编写所有代码。 / li>
  
• 功能集与大EF相比有限。


• 没有任何文件，目前您必须在博客中查找信息。

目前我正在使用第一种方法。在最终版本之后，我可能会更快乐地使用代码。

The ability to separate domain objects completely from any kind of persistance code makes systems much more extensible and maintainable. Testing is made much easier when business logic can be tested separately from storage code. The use of POCOs with the Entity Framework (EF) is definitely a step in the right direction :)

there are 2 types of using poco with EF 1.Using the entity designer 2.Using the code only

which one is the best approach EF poco code first or EF Poco using the entity data model designer ?

thanks

解决方案

It is just a matter of choice.

EFv4 with designer

Pros:

• You have designer support and T4 template which will generate entities for you = RAD.
• You have very big feature set including support for views, stored procedures mapping and some custom model defined objects like QueryView or Model defined function.
• Support for other EF types when needed (Self tracking entities, Entity objects).

Cons:

• Designer is not very good tool for big models (50+ tables)
• Not all features are supported in designer - you must access EDMX as XML
• EDMX XML structure is probably the most complex and hard to understand description among all available .NET ORM tools
• Working in shared environment with designer is just a pain - it is better to use exclusive locks on EDMX
• Edit: I forgot my very popular drawback. Designer stores all mapping data in EDMX together with its own data about positioning entities in diagram. Even such stupid action like zooming diagram will check out the EDMX file from source control.

EF code first

Pros:

• Ability to define everything in code
• Attribute based mapping and Fluent API
• Some very nice API features - conventions, Local, etc.
• I think this API is less complex and easier to use

Cons:

• It is not final release yet. Current release is only community technology preview 5.
• Because of that API can change in final release.
• You must write all code by yourselves.
• Feature set is limited compared to "big" EF.
• There is no documentation, currently you will have to look for information in blogs.

Currently I'm using the first approach. After final release I will be probably more happy with code first.

这篇关于EF POCO代码只有VS EF POCO与实体数据模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！