EF + SQL Server：代码优先还是数据库优先

Question

我有一个用ASP.Net 2.0 Web Form编写的系统。与MySQL服务器交流的框架非常酷。它读取服务器表单标签或面板内的所有控件，并在目标表上执行CRUD操作。

当我创建CRUD页面时，我只需要在数据库用户{id，name，password，createdate}中创建表，并且我只需要使用id作为表中的确切列名。这些控件可以是输入/选择/选项/ chekbox/textarea，甚至可以是页面上的FCK编辑器或CK编辑器。该框架遍历面板内的所有控件并保存/编辑/删除。如果我想添加一些新的字段，电子邮件和移动设备，我只需要在页面上添加两个控件，并在表格中添加两列。而已。我不必在page.aspx.cs文件，实体层，业务层或数据访问层中更改任何内容。这是非常容易实施和维护。

我们希望升级系统以使用ASP.Net 4 MVC3与Entity Framework CT5。我们将从头开始重建整个系统。我希望这里的一些专家能够给我一些指点。我发现了以下两个选项来重建系统。

1. Code First 我们的新系统将完成与上述框架完全相同的操作。它将遍历所有Request.Forms数据，并将它们与其数据库中的关联表映射并保存/更新/删除所有数据。为此，view将发布表单数据，控制器将接受Entity类的值并通过EF将它们保存到数据库中。我仍然需要创建ViewModel类来在View上显示数据。如果有添加电子邮件和移动字段到用户页面的任何更改，我仍然需要更改三个位置查看，实体（域类）和ViewModel。我不必在数据库中更改任何内容，因为EF会自动运行ALTER TABLE以添加两个新字段。我仍然不知道如何最小化实体和视图模型类的需求。

2.数据库首先 我真的不喜欢这种方式，但我会，如果这个解决方案提供了更灵活的操作。我将在数据库中创建列，系统将动态创建ViewModel（我仍在弄清楚如何执行此操作），读取表中的所有列，并在页面上显示数据。当视图发布数据时，它需要动态创建实体类并将更改保存到数据库。编辑： 升级当前系统的原因。

• 我们希望使用新功能的动力是.NET 4中的LINQ，实体框架，不显眼的JavaScript库，easifer使用JSON数据工作，远程验证（我们可以使用RequireFieldValidator，RegExValidator在当前的系统，但他们是有限的，例如：对输入复选框和选项进行验证），用var和界面进行鸭子打字。

Answer 1

我们的新系统也将这样做完全一样的操作与上述 框架。它将遍历所有的Request.Forms数据，并将它们映射到数据库中的关联表 ，并保存/更新/删除所有的 数据。为此，查看将发布表单数据，控制器将 接受实体类的值并通过EF将它们保存到 数据库。

如果我在这里错过了某些东西，有人请拍我，但这些说法似乎与我矛盾。如果你想要一个能够自动解析请求的系统。形成数据并将它们直接映射到数据库表，那么为什么您需要使用Entity Framework（或任何其他类型的中间件）呢？ EF或任何ORM的要点是创建一个有意义的代表系统名词的概念数据对象集合。然后，您对这些名词进行操作，影响它们的属性或访问它们的行为，并让ORM找出如何将它们映射到表+列。

要回答你的问题，这听起来像你想要的最简单的解决方案，这意味着你必须写最少量的代码。如果这是一个正确的假设，那么您可能首先需要使用数据库。你可以让EF生成你的实体类，但就像你说的那样，你仍然需要手动创建viewmodel类或者想出一些AOP（使用T4也许）来为你生成这些类。但是，无论何时，如果您给工具提供了为您生成某种东西的权力，那么您就无法控制它。

我第一喜欢的代码首先/ 概念模式，但我也很喜欢（从基础设施问题可以交给工具和像AutoMapper，EF，T4MVC等框架除外）拥有了一切完全控制应用程序。是的，这是更多的工作，因为我必须创建实体类，视图模型类和视图（以及控制器，动作过滤器和html助手，还有其他）。如果你的域名是你可以直接将文本框映射到数据库表格&列的域名，那么这可能对你来说太过分了。