大型项目的实体框架

本文关键字：框架 实体 大型项目 | 更新日期: 2023-09-27 18:14:47

我和我的团队将要开始一个新的项目，我们正处于探索和测试一些新的(或不太新的)技术的阶段。

直到今天，我们还在使用经典的ADO与dbdatareader，延迟加载代理和某些情况下的数据表。

团队由3名开发人员和1名数据库设计人员组成。我们的项目每个至少包含130个表。

我们的新项目有增长的潜力，所以我们预计肯定会有100张表。

我一直在阅读和做一些简单的测试与EF5在过去的两天，我仍然不能决定我们是否应该使用它。

    我们通常将一个大项目分成许多"模块"项目，使我们能够在源代码控制下更快更好地工作。我们要对整个DB使用一个大的"edmx"吗?
  1. 因为我们有一个数据库设计器，我怀疑CodeFirst不是一个选项。那么，是否值得将EF与数据库优先方法一起使用呢?
  2. 如果我们首先使用数据库方法，EF是否足够智能，可以正确检测所有关系，并准备好使用，而无需我进行更多的额外配置?(通过额外的配置，我的意思是我将不得不写数据注释或必须覆盖DbContext)
    3. 就我个人而言，我发现我自己很有信心设计一个数据库与sql。我唯一的烦恼是，当一个实体在我的类列表中改变时，我必须更新所有的选择，删除，更新，插入脚本。EF会为我处理这个问题，但除此之外，我开始相信它会降低性能，并最终降低我的生产速度，因为我们不熟悉它。

你认为这值得吗?

*除了data_annotations和DbContext覆盖，有人使用普通T4模板来创建表(模式)吗?

大型项目的实体框架

  1. 我绝对建议创建多个模型。您可以为每个表选择映射哪些表、视图和存储过程。
  2. 数据库优先绝对没问题。
  3. 如果数据库约束已经设置，那么EF将识别它们。你不会绕过一些小的修改，但总的来说，EF做得很好。
  4. 使用EF会对查询性能产生轻微影响。但在大多数情况下，这不是问题。在少数情况下，您可能会遇到无法接受的性能损失，您可以通过在必要时将自己的SQL注入EF来进行优化。

我想你们很快就会熟悉EF的用法，所以我认为不熟悉不会是一个长期的问题。

我决定不使用EF。我不打算冒险在一个大项目中使用它。

使用它所需的所有工作，处理错误的可能性，额外的开销…比起处理生成的模型或检查生成的查询的sql分析器，我更喜欢编写更多的sql代码并花更多的时间进行维护。

感谢大家的评论。

*在我再次直接ADO之前，我会给FluentData和Dapper一个镜头。我将打开一个新的问题，所以如果你们想评论这两个轻型orm，我稍后会发布链接。

如果您的数据库结构成熟，EF应该是一个很好的解决方案。

如果数据库结构正在开发中，或者随着时间的推移会发生很大变化，我认为EF可能不是最适合您的。

EF需要在发生结构更改(以及可能在数据库层发生的接口更改)时进行刷新。您应该考虑如何在已经开发的代码库中管理数据库更改。

相关文章：