CodeFirst是否适用于大规模应用？

我一直在阅读Entity Framework，尤其是EF 4.1，并点击此链接（http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx）及其有关代码优先的指南。

我觉得它很整洁，但是我想知道，Code First是否应该只是快速开发的解决方案，而您无需进行太多计划就可以直接投入使用，或者它实际上打算用于大规模应用程序？

我可能有一些批评者，但是当我阅读Hanselman和Gutherie的一些文章，然后阅读Julia Lerman关于Entity Framework 的书时，我首先很难编写代码。在多年构建应用程序的过程中，我走了许多条路，无论是受过程还是出于选择，都发现我在构建应用程序时以数据为中心的观点取得了更大的成功。

我在这里谈论的是业务应用程序...这是当您遇到业务问题或流程需要在其背后提供软件解决方案时。您需要以某种方式管理数据。最好了解您的数据及其与自身的关系以及在业务中的使用方式。因此，您可以对数据建模，然后围绕它创建一个应用程序/解决方案。以我的经验，如果您事后才开始使用数据创建应用程序，则最终会遗漏某些内容，然后进行一些重构（在许多情况下为MAJOR重构）。

小型应用程序可能是个例外，但是我将继续使用以数据为中心的方法。

我不明白为什么CodeFirst无法在大型企业项目中使用。我会说我在多个项目中使用EF CodeFirst，其中一个项目由我的EF CodeFirst模型生成数据库，第二个项目中将EF CodeFirst映射到现有数据库。

根据我的经验，CF在大型项目中的有效程度在很大程度上取决于数据层与业务层之间的抽象程度。

例如，在我的一个项目中，业务层通过linq直接调用数据库。我使用Linq提取数据库层，并使用CodeFirst将POCO映射到数据库模式。在这种情况下，CodeFirst大大简化了维护数据库约定（关系和表名）与我的C＃类名之间的差异的操作，并且我可以进行数据库更改而不必严重影响业务层与数据库的交互方式。

但是，在另一个项目中，我已经将数据库访问抽象为非通用存储库模式，而我的存储库的Get *方法仅负责在数据库上运行查询，并且它们返回真实对象（不是IQueryable<T>）。在这种情况下，存储库方法将DB实体转换为POCO实体，在这种情况下，由于CodeFirst POCO寿命短且可以迅速转换为业务层C＃类，因此CodeFirst不会为您提供太多好处。

最终，这实际上取决于团队的结构以及团队（或上级）对非DBA工程师修改数据库模式的适应程度，以及多少模式更改将影响您的代码结构。将CodeFirst映射到现有数据库后，对于我来说，将属性重新映射到新的列名而不必对该属性名进行全局重命名就很简单了，当您谈论一个更有意义的名称时，这尤其重要用于数据库字段而不是C＃属性。对我来说，为新的数据库字段添加代码支持而不必完全重塑我的C＃实体（这也是我从现有数据库中将Linq-to-sql留给EF CodeFirst的原因之一）也很简单。

Code First不适合大规模应用。大型应用程序的开发周转非常巨大。

通常，您的业务应用程序的生命周期如下：

1. 版本1已投入生产
2. 第2版​​为Beta
3. 版本3正在积极开发中
4. 第4版正在计划中。

还有其他跨应用程序通信桥，一些计划任务，一些第三方集成，用于某些不同通信设备（例如移动设备）的Web服务。

最终，代码优先使用实体​​模型的ObjectContext，较旧的EF生成EDMX，并将ObjectContext与EntityObject结合使用确实可以满足所有需求。您可以轻松地自定义文本模板以生成代码。使用ObjectContext实现时，“检测更改”方法的速度较慢，但​​是EF团队可以轻松地提高“检测更改”的速度，而不必首先重新编写代码，而无需生成代理。

自动迁移

从理论上讲，自动迁移听起来不错，但是一旦上线，在实践中就不可能了。它仅适合于原型设计，开发一些快速演示。

代码优先迁移根本不适合这种系统。版本1和版本2最有可能与同一个数据库对话。版本3和版本4通常是临时的，并且具有不同的数据库。

数据库优先

Database First是一种实用的方法，它易于比较，可视化和维护SQL脚本。DBA可以轻松使用。

文字范本

我们创建了自己的文本模板来查询和创建EDMX和ObjectContext，而几乎没有解决性能问题的自定义实现。有多个版本不同的应用程序可以同一个数据库通信，而不会出现任何问题。

对我来说，右键单击.tt文件，然后单击“运行自定义工具”，这是迄今为止最快，最简单的步骤，然后编写类，配置和创建模型。

通常对于大型项目，已经创建了数据库。因为它是旧数据库，或者是由主管dba为提高性能而创建的。CodeFirst的唯一好处是，如果您不想使用EF的实体，而是使用POCO。

在我看来，“代码优先”是指将EF与“敏捷”功能结合使用（不要过度用词，我不一定要指的是方法论）和未开发的应用程序现有数据模型或现有数据；您也可以使用Django，PHP框架或Rails遵循这些框架的准则的应用程序，这些准则通常涉及将数据模型作为代码的一部分，而不是围绕传统的数据模型构建应用程序Microsoft处理事物的方式。

因此，要回答这个问题，我会拒绝。如果您已经有现有数据，并且正在创建一个应用程序来处理它，则Code First的意义不大。但是，我根本没有使用过EF，更不用说使用代码优先EF了，看来这是一种松散耦合的编码方法，总是有好处的。假设您可以使用Code First，然后仍将类指向现有的数据模型（而不是被迫生成模型），那么Code First方法仍然可以帮助编写正确的抽象和可测试的代码，而无需使用所有通常的“习惯”实体框架（即生成的元类）。

我会说在非常大的项目中，代码优先是没有意义的。

实际上，当项目规模很大时，您通常会严格分离关注点。您不能在Photoshop中由同一个人编写C＃代码，进行数据库设计，编写HTML / CSS以及进行视觉设计。而是由数据库管理员（或至少由知道她的工作的专门人员）完成数据库设计。

由于数据库是由熟悉数据库，SQL和管理以及数据库设计工具的人员设计的，因此看到这个人使用实体框架会很奇怪。

此外，我不确定Entity Framework是否足够强大以正确设计数据库。索引呢？约束？意见？

代码首先适用于大型系统：只需在创建后检查模型，并使用流畅的api重新映射，直到获得所需的数据库模型。