我已经阅读过Code First Migrations,但它似乎并不适合企业版.
我们有一个DBA可以完成所有数据库更改,我们不需要将这些更改放入类中并由应用程序执行数据库迁移.
如果我们更改我们的类和流畅的API然后让我们的DBA对数据库进行更改,那么我们如何同步到我们的EF模型?这通常如何为企业规模应用程序完成?
即使我使用EF Code First风格(而不是EDMX),我仍然在技术上使用数据库第一种方法,因为我从不让EF为我生成数据库.相反,我创建了类来建模数据库.这听起来像你需要做的事情.
至于DBA更改事物..是否需要更新域实体类取决于DBA正在改变的内容.例如,如果他正在增加一个varchar(100)to varchar(200)或类似的长度,那么这个改变不应该真正破坏你的代码(但仍然建议你更新你的代码以匹配它).如果他正在删除或重命名某些列,那么你肯定需要更新你的域实体类,因为这显然会导致基础模型不同步的异常.
对我来说,似乎这些其他答案都不够.
您可以关闭EF初始化程序:
public ApplicationContext : DbContext
{
public ApplicationContext()
: base("ConnectionStringName")
{
Database.SetInitializer<ApplicationContext>(null);
}
// DbSets here
public DbSet<Part> Parts {get; set;}
// override OnModelCreating below ...
}
Run Code Online (Sandbox Code Playgroud)
然后使用Fluent API /数据注释,但通常会设置POCO /模型以匹配现有数据库.
此博客的详细信息:http://cpratt.co/entity-framework-code-first-with-existing-database/
如果URL在将来不起作用 - 这就是我的意思:
在上面设置了初始化程序后,配置与表对应的POCO:
public class Part
{
public string PartID {get; set;}
public string Description {get; set;}
public decimal Weightlbs {get; set;}
public decimal Price {get; set;}
}
Run Code Online (Sandbox Code Playgroud)
然后通过在您的Application Context类中重写此方法将POCO映射到现有数据库表:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
// Code First will assume a lot, but if you need to override things:
modelBuilder.Entity<Part>().ToTable("db_PartTable");
modelBuilder.Entity<Part>().Property(p => p.PartID)
.HasColumnName("Part_ID");
modelBuilder.Entity<Part>().Property(p => p.Description)
.HasMaxLength(100)
}
Run Code Online (Sandbox Code Playgroud)
Scott Guthrie的另一个好博客:http://weblogs.asp.net/scottgu/using-ef-code-first-with-an-existing-database
通常在这种情况下,人们使用数据库优先方法。
当有人已经为您设计了数据库并且您可以通过几次点击生成或更新模型时,手动编写实体代码是没有意义的。当然,如果您的团队熟悉其他一些 ORM(它是主要方法)并且不太熟悉实体框架,或者如果您的团队非常小并且没有人可以编写 SQL 脚本,那么 Code First 可能会很方便,但是如果您有熟练的 DBA,为什么需要 Code First?
| 归档时间: |
|
| 查看次数: |
6697 次 |
| 最近记录: |