I'm trying to kick off a project needing table-per-hierachy. I've done this in the past with NHibernate, but we want to avoid having to hand edit XML mapping files - so are trying to use Entity Framework and it's Designer.
I've been following this example online:
http://mosesofegypt.net/post/Inheritance-and-Associations-with-Entity-Framework-Part-1.aspx
When trying to select a Table from the "<Add Table or View>" dropdown, I can't select any tables, instead the list shows "(Empty)".
The only deviation I've made from the tutorial is that I didn't generate the Person table off the sample database, as far as I can tell this shouldn't make a difference (we want to generate the DB off the model, not vice versa).
Not sure what criteria a table needs to meet to be eligible to add a discriminator to...
If you need to generate DB from the model you cannot see any table in mapping because both mapping and information about tables is generated when you generate the database. EDMX has quite complex structure (much more complex than very easy hbm files for NHibernate). The complexity is even worse because EDMX doesn't have anything implicit - everything must be described and it must be described three times.
EDMX consists of three parts:
CSDL - conceptual model you see in the designer (classes)
SSDL - database description - this can be browsed in model browser but it is read-only
MSL - mapping between SSDL and MSL (that is what you are trying to edit in that window).
When you are going to use model-first (draw entities in designer and generate database) you define only CSDL and everything else is generated with SQL for the database. You will also probably need another template / workflow for DB generation because I guess it will by default use Table-per-type inheritance. Check Database generation power pack - it should contain template for TPH.
Related
Can a Model First approach in MVC be implemented by avoiding the UML designer file? In my previous company Entity Model was written in a Xaml file. Then we used to run a T4 template tool and then get an Edmx file by choosing Generate views option. This would create class file and SQL scripts for procedures, Table Valued Functions which we later execute in SQL server to create database.
I am confused whether its code first or model first approach as we had not used any diagram to create entity relation.
This is model first.
But IMO "model first" is a misnomer making it more confusing than it should. In fact, it's "mapping first". An object-relational mapper (ORM), like Entity Framework, always deals with three main components --database, object-oriented code and the mapping between these two. Any of these three parts can be created first.
The other flavors are "database first": first the database, then the mapping (edmx) then the code (running t4 templates) and "code first: first the code, then the mapping (conventions, data annotations, and/or fluent) then the database (migrations).
I have been using Database First Entity Framework (EDMX) and SQL Server Data Tools Database Projects in combination very successfully - change the schema in the database and 'Update Model from Database' to get them into the EDMX. I see though that Entity Framework 7 will be dropping the EDMX format and I am looking for a new process that will allow me to use Code First in Combination with Database Projects.
Lots of my existing development and deployment processes rely on having a database project that contains the schema. This goes in source control is deployed along with the code and is used to update the production database complete with data migration using pre and post deployment scripts. I would be reluctant to drop it.
I would be keen to split one big EDMX into many smaller models as part of this work. This will mean multiple Code First models referencing the same database.
Assuming that I have an existing database and a database project to go with it - I am thinking that I would start by using the following wizard to create an initial set of entity and context classes - I would do this for each of the models.
Add | New Item... | Visual C# Items | Data | ADO.NET Entity Data Model | Code first from database
My problem is - where do I go from there? How do I handle schema changes? As long as I can get the database schema updated, I can use a schema compare operation to get the changes into the project.
These are the options that I am considering.
Make changes in the database and use the wizard from above to regenerate. I guess that I would need to keep any modifications to the entity and/or context classes in partial classes so that they do not get overwritten. Automating this with a list of tables etc to include would be handy. Powershell or T4 Templates maybe? SqlSharpener (suggested by Keith in comments) looks like it might help here. I would also look at disabling all but the checks for database existence and schema compatibility here, as suggested by Steve Green in the comments.
Make changes in code and use migrations to get these changes applied to the database. From what I understand, not having models map cleanly to database schemas (mine don't) might pose problems. I also see some complaints on the net that migrations do not cover all database object types - this was also my experience when I played around with Code First a while back - unique constraints I think were not covered. Has this improved in Entity Framework 7?
Make changes in the database and then use migrations as a kind of comparison between code and the database. See what the differences are and adjust the code to suit. Keep going until there are no differences.
Make changes manually in both code and the database. Obviously, this is not very appealing.
Which of these would be best? Is there anything that I would need to know before trying to implement it? Are there any other, better options?
So the path that we ended up taking was to create some T4 templates that generate both a DbContext and our entities. We provide the entity T4 a list of tables from which to generate entities and have a syntax to indicate that the entity based on one table should inherit from the entity based on another. Custom code goes in partial classes. So our solution looks most like my option 1 from above.
Also, we started out generating fluent configuration in OnModelCreating in the DbContext but have swapped to using attributes on the Entities (where attributes exist - HasPrecision was one that we had to use fluent configuration for). We found that it is more concise and easier to locate the configuration for a property when it is right there decorating that property.
I've been using EF for a while (4 with model first) and so far I've not created any mapping manually. Whenever I need more entities/tables, I add an entity and the associations (all foreign key) and click "update database from model", which, as is well known, doesn't update any database from the model (although it does need a database connection for reasons I don't know). What it does is generating a storage model and the appropriate mappings to it, which are all stored back to the same edmx xml file.
So far, that has always been enough for me but I'm wondering what the workflow would be if one is to tweak the mappings and storage model manually. "Update database from model" overwrites all manual customization - so how is one to fix most of the mappings and storage model? Because I clearly don't want to do it all by hand - in fact I couldn't even figure out how to actually create a table in the storage model other than by editing the edmx in the xml.
I have the same problem. I just use a mixture of methods. If I add a field to the database, I just add the field to the model file. If I do a major restructure, I delete the table and recreate it by generating it from the database. Sometimes, I actually edit the edmx as XML to change or add things. You just kinda gotta figure out what process works best for you. I have managed to avoid heavy customization in the edmx by using the T4 template or changing the database and regenerating.
Trying to understand Entity Framework. My approach is database first. However I would like to define other entites in the model that is closer to my business objects. I guess I could write queries in the db and include them in the model. But I would also like to define entirely new entities in the model though they would be based on underlying tables in the db. How do I do that - does anyone know a tutorial?
Regards
Bjørn
db Oldtimer, EF Newbie
Database first means that you have existing database and you can either create model by updating from database or manually. You can use wizard to create initial model and modify it manually to define new entities but you must not use update from database any more or some of your changes will be deleted. Also your custom modifications must follow EF mapping rules (for example it is not directly possible to map multiple entities to the same table except some more advanced mapping scenarios like splitting and inheritance) and some of them (custom queries) must be done directly in EDMX source (XML) because designer doesn't support them - this requires more complex knowledge of EF mapping and it will be definitely hard for newbie.
You can check specification of that XML. For entities mapped to custom queries you will have to use DefiningQuery element in SSDL part of EDMX.
If we've been using an Entity Framework 4 model for some time, and we eventually want to switch the underlying database to a different vendor's product (say, from SQL Server to MySQL), is it simple to adjust the table and column mappings in the entity model without needing to update any of the entity class code?
We're trying to design code that is as database agnostic as possible, so I'd like to know in advance how much trouble we're in for if we ever switch our databases around. Ideally, we'd like to not have to touch our applications that use our entity classes. I can't seem to find any way in the entity designer or XML editor to adjust the underlying database column names without it giving me an error.
(I can, however, edit the entity's property names in the designer while leaving the database column names alone, but that's the opposite of what I need.)
Thanks!
EDMX is not database agnostic. SSDL part of EDMX is tightly coupled with database server (in case of MSSQL even with its version). You need separate SSDL for each supported database server.
I don't understand how changing column names relates to database agnostic model. Reverse is true! If you need your database to have different column names for different server products you need separate mapping for each of them!
Changing column names when using model first is possible only if you modify T4 template used for generating database creation SQL script. But every time you create that script designer will delete whole your storage description (SSDL) and mapping (MSL) and replace them with a new one.
The easiest way to have database agnostic code is using code first but even then you can have problems with some type and feature inconsistency among servers.
If you want database agnostic ORM you should probably check NHibernate.