I\'m investigating replacing or supplementing our home grown ORM system with the Entity Framework 4, and I\'m noticing that the latter may end up causing a conflict between
The correct solution is to change your database naming convention.
Why should the tail wag the dog? In modern programming most of the action takes place in the highly scalable business/service layer, not the database. Programmers should use a naming convention that works for both - and it should cater to the needs of the application developer who is going to be working with these objects day in and day out. In some cases it should probably cater to the needs of the front end developer, in others the server side.
The whole purpose of a naming convention is to reduce complexity. Yet the accepted solution here is to implement all kinds of additional complexity. And every other ORM would have to come up with their own convoluted solution to this artificial problem.
You can do it . You need to implement a custom model builder to map your entities with relevant tables and relevant columns. You can override OnModelCreating function to build a custome model by adding this function to your context class.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<EntityName>().Map(c => c.ToTable("TableName"));//to map entity with table
modelBuilder.Entity<EntityName>().Property(s => s.Property).HasColumnName("ColomnName");//to map properties with colomns
}
Sure there is. There is T4 template which converts your model to SQL DDL scripts. You can make a copy of this template and put your own logic for name generation into the new copy. After that you just need to set this template in your designer (DDL Generation Template property) and run Generate Database from Model ...
You will find default template in:
%VSINSTALLDIR%\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\DBGen\SSDLToSQL10.tt