使用EntityFramework反对什么参数？[关闭]

我当前正在构建的应用程序一直在使用存储过程和手工制作的类模型来表示数据库对象。有人建议使用Entity Framework，由于我对项目的了解并不多，因此我正在考虑切换到该框架。我的问题是，我觉得为EF争论的人只是在告诉我事情的好处，而不是坏的事情:)

我主要关心的是：

• 我们希望使用DataAnnotations进行客户端验证，这听起来好像我还是必须创建客户端模型，所以我不确定EF是否会节省那么多编码时间
• 我们希望通过网络时使类尽可能的小，并且我读到使用EF通常会包含不需要的额外数据
• 我们有一个跨多个数据库的复杂数据库层，我不确定EF是否可以处理此问题。我们有一个Common数据库，其中包含诸如Users，StatusCodes，Types等内容，以及针对应用程序不同实例的主数据库的多个实例。SELECT查询可以并且将在数据库的所有实例之间进行查询，但是用户只能修改当前正在使用的数据库中的对象。他们可以在不重新加载应用程序的情况下切换数据库。
• 对象模式非常复杂，通常涉及很多联接

EF的参数为：

• 并发。我不必在检查中编写代码以查看记录是否在每次保存之前都已更新
• 代码生成。EF可以为我生成部分类模型和POCO，但是我并不肯定这会为我节省很多时间，因为我认为我们仍然需要创建客户端模型进行验证和一些自定义解析方法。
• 由于我们不需要为每个数据库对象创建CRUD存储过程，因此可以加快开发速度

我们当前的体系结构由WPF服务和WPF桌面客户端组成，该WPF服务通过参数化的存储过程处理数据库调用，从WCF服务和WPF客户端传入/传出的POCO对象，以及将POCO转换为类模型以进行验证和验证的WPF桌面客户端本身。数据绑定。

所以我的问题是，EF是否适合这样做？我没有意识到关于EF的陷阱吗？

我最近正在评估Entity Framework，发现问题和缺少功能的最佳位置是：http : //data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

得票最多的项目：

1. 支持枚举。这个很大，但是目前有一些解决方法
2. 改进的SQL生成。速度确实非常重要，特别是对于企业级应用程序而言，但是对于EF4而言，速度似乎已经有了很大的提高
3. 支持多个数据库。任何大型应用程序的要求。

用户语音列表中还有更多问题。

附带说明一下，我对即将发布的EF 4.1感到非常兴奋，该版本将包括Code-First方法... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-candidate-available.aspx

这实际上可能促使我在生产应用程序中尝试EF。

在合并时，使用EF进行每个错误的分支/功能会非常痛苦。想象一下，两个分支A和B对数据库进行了更改（在新项目的早期阶段可能会发生很多事情）。

您合并了所有“普通”文件-cs文件等。然后是时候合并Model.edmx。突然之间，您不仅要合并对象模型和数据库之间的逻辑映射，而且要合并表在实体图中的位置。

合并Model.edmx非常痛苦，我们采用了一种相当讨厌的方式：

• 在合并期间，只需从一个父级中选择所有合并。没关系；无论如何，您都会很快敬酒该文件：
• 将Model.edmx还原为任一父级。
• 将数据库迁移到新的合并状态。
• 打开Model.edmx，然后单击“从数据库更新模型”。
• 重命名在合并过程中烤制的所有导航属性。

您还缺少EF的其他一些好处：

• 您可以有一个实体跨度表
• 您可以将表格分为多种类型的实体
• 您可以从数据库生成实体（即数据库作为主方法）
• 您可以从实体生成数据库（即，将代码作为主要方法）
• LINQ查询被转换为SQL查询，从而提高了性能。

缺点（特别是如果您使用验证）：

• 您必须创建一个[MetadataClass]属性，该属性指向具有要使用适当的验证属性进行验证的属性的另一个类。所有属性都是object类型，因此可以在其中读取元数据。仍然有很多额外的非活动代码。
• 使用EntityFramework与NHibernate（以及父Java版本）的设计工作方式不同。在对象始终使用实时连接的附加模式下，EntityFramework的效果最佳。NHibernate和类似的ORM工具在分离模式下最有效，分离模式仅在加载/保存数据时使用连接。

这是我最大的两个抱怨。有很多好处，但是您很可能可以从NHibernate中获得同样的好处。如果桌上有EntityFramework，请团队也检查NHibernate并快速射击出您项目的利弊。

元数据类的问题令人头疼，但值得庆幸的是，我只有这么多需要验证标签的实体。

缺少真正的对象分离模式会限制您在Web环境中可以执行的操作。附加模式更适合桌面应用程序，这是许多Microsoft创新的起源。分离模式是可能的，但是非常痛苦。在这种情况下，最好使用替代工具。

有一件事微软不太擅长落后可比性的兼容性，特别是当它涉及到新技术

特别是EF1（.net 3.5）与EF4（.net 4.0）有很大的不同-下一个版本可能会出现相同的情况。

我将等待一段时间，看看技术如何成熟。

同时，考虑使用nHibernate-它不是等效的，但已经成熟并且被广泛使用。

• 简而言之...域模型很少是数据库中关系模型的副本。因此，将某些表映射到一个类并将其扔到网上仅仅是个懒惰。即使数据库是3个不同的表，表也可能在本地映射到1个对象。智能地设计数据库。
• 第二，这些EF内容无法生成某些查询，无论如何您都必须编写它们。
• 第三，域模型不会直接映射到服务上。.一个人只想作为DTO通过有线方式推送最少量的数据集。尤其是当它要与移动应用程序通信时。
• 5th可测试性...无法创建足够细致的测试，无法针对代码更改提供足够的回归...所有这些都很容易
  打破...

我可以写一个10页的diatribe。但是，如果您只是为X公司写一些扔掉的应用程序，那么谁在乎。但是，如果您要开发软件产品，那么您将不得不付出更多的努力。

检查一下：http : //efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

要点如下：

• 缺少延迟加载
• 缺乏持续性的愚昧
• 用于保存实体模型的文件格式包含可视化元素，并且实体模型本身在团队环境中导致合并问题。

请注意，上面的链接正在谈论EF1。

另外，此链接：http : //ormeter.net/显示，在性能和LINQ支持方面，EF与其他ORM相比并不是最好的。