EDMX图中使用实体框架4.1代码优先优于模型/数据库优先的优点和缺点是什么?
我试图充分理解使用EF 4.1构建数据访问层的所有方法。我使用存储库模式和IoC。
我知道我可以使用代码优先的方法:手动定义实体和上下文，并使用ModelBuilder对模式进行微调。
我还可以创建一个EDMX图并选择一个代码生成步骤，该步骤使用T4模板来生成相同的POCO类。
在这两种情况下，我最终得到的POCO对象是ORM不可知的，而上下文则来自DbContext。
数据库优先似乎是最有吸引力的，因为我可以在企业管理器中设计数据库，快速同步模型并使用设计器对其进行微调。
那么这两种方法有什么不同呢?仅仅是VS2010 vs企业管理器的偏好问题吗?
当前回答
依我之见，我认为所有的模型都有很好的地方，但我认为模型优先方法的问题是，在许多大型企业中，DBA控制数据库，如果不使用数据库优先方法，就无法获得构建应用程序的灵活性。我参与过许多项目，当涉及到部署时，他们想要完全控制。
因此，尽管我同意所有可能的变化，代码优先，模型优先，数据库优先，您必须考虑实际的生产环境。因此，如果您的系统将是一个拥有许多用户和DBA的大型用户基础应用程序，那么您可能会考虑数据库作为首选——这只是我的观点。
其他回答
我认为Julie Lerman(《Programming Entity Framework》的作者)所写的这棵简单的“决策树”能够帮助我们更自信地做出决定:
更多信息在这里。
在SP1之前，使用大型机型的速度非常慢(SP1之后还没有尝试过，但据说现在很容易)。
我仍然先设计我的表，然后内部构建的工具为我生成poco，因此它承担了为每个poco对象执行重复任务的负担。
当你使用源代码控制系统时，你可以很容易地跟踪poco的历史，而使用设计器生成的代码就不那么容易了。
我的POCO有一个基础，这使得很多事情变得非常简单。
我有所有表的视图，每个基本视图为外键带来基本信息，我的视图POCO派生自我的POCO类，这是非常有用的。
最后，我不喜欢设计师。
我认为代码优先的优点之一是，你可以备份你对版本控制系统(如Git)所做的所有更改。因为所有的表和关系都存储在本质上只是类中，所以您可以回顾过去，看看数据库以前的结构是什么。
依我之见，我认为所有的模型都有很好的地方，但我认为模型优先方法的问题是，在许多大型企业中，DBA控制数据库，如果不使用数据库优先方法，就无法获得构建应用程序的灵活性。我参与过许多项目，当涉及到部署时，他们想要完全控制。
因此，尽管我同意所有可能的变化，代码优先，模型优先，数据库优先，您必须考虑实际的生产环境。因此，如果您的系统将是一个拥有许多用户和DBA的大型用户基础应用程序，那么您可能会考虑数据库作为首选——这只是我的观点。
数据库优先方法示例:
无需编写任何代码: ASP。数据库优先/数据库优先
我认为它比其他方法更好，因为这种方法数据丢失更少。
