When we made initial release of our model we had the following model
1. Person:String:Name,String :Address
2. Version : 1.0
so export /import was easy using EMF's persistent APIs(Storing them as xmls).
Now we have changed the model to
1. Person :String:Name,Address
2. Address: String:House Number, String:Stree Name, String:City
3. Version : 2.0
The same thing explained below
Now how to support older xml files(which are exported using old model) in the new Model.
Is there any support in EMF to do this?
There are some tools/frameworks to help with model migration. Edapt is probably the most well-known (and an official Eclipse project). Basically, it includes tooling and runtime support that tracks the history of your metamodels and can migrate instances at runtime. There was a talk about it at EclipseCon earlier this year.
I've also heard of another project, EMF Migrate, but I don't know much about it.
Related
We are starting a new large corporate project. The database will be 100+ tables and we will be using Entity Framework, Web API and MVC.
My question is specifically related to the Entity Framework aspects of the solution.
I am trying to make a choice between the following:
Code first to an existing Database
EF Designer to an Existing Database (Database First)
I know we can use EF to generate the database from code first or from the EF designer, but we prefer to have full control over the database and develop that in the traditional way, so we have excluded the EF options that allow us to auto-generate the database.
Most of what I can find on the internet relating to Code First deals with creating a new database and then using code migrations. And when the discussions deal with Database first then the discussions favour the EF Designer. Example here: Code-first vs Model/Database-first
My preference is to go with the combination of Code First to an existing database.
The following are my considerations for favouring this option and I'm wondering if there is anything else I need to consider, and whether my assumptions/thoughts are correct.
Code first to an Existing database
There will be a large number of classes to construct at the start, but we could do the initial generation from the EF Model Wizard.
The classes could then modified with any custom properties or to remove anything we don't need, rather than the EF Designer that would require us to extend any classes.
The disadvantage is that any changes to the database would have to be manually added to our classes, unlike using the designer which will allow easy updating.
Edit:
I think I was confused in this area. From reading, it appears that the correct way to do Data First is to create partial classes for all the auto generated classes, and then to make any modifications to the partial classes as part of the 'business' layer.
My thought has therefore changed from favouring the Code First from Database, to using the EF Designer to existing database and then creating the partial classes.
In any case you'll have to synchronize the EDM (entity data model) and the DB. You have to make sure that the EDM is fully compatible with your database. If not, it will fail, no matter if it's Code First or you use a Model.
The only difference is that:
using the designer you can do it graphically, and easyly set properties, column names, and so on
using Code First, you have to set these properties, columns names, data types and so on using conventions, Fluent API or attributes
With Code First the only advantage is that once you've synchronized the Code First model (see "Code First is also an EDM, but somewhat limited") and the database, you can start using Migrations, and evolve your model using them, which later makes it easier to apply changes to the production DB (whenever a new version is released). With graphic model you cannot use migrations, and have to upgrade the Db directly from Visual Studio, or creating SQL DDL scripts by hand.
Code First is also an EDM, but with a few missing functionalities
It doesn't matter if you use Code First or draw a model, an EDM (entity data model) will be generated. If you're used to design databases, probably you'll be more comfortable using the designer. Beware of the notes on EF Core (former EF7) below!.
However, the EDM generated by Code First has a few limitations that the designer doesn't have.
The most outstanding limitations of Code First is that in the designer you can easily map user defined functions from the BD, for example scalar and table value functions, and stored procedures. With Code First there are much more limitations.
in EF 6.1 most of this limitations dissapear, but it's still a bit difficult to make the mappings.(In fact, as of today, 2014, there's only a sample, and a simple Nuget package on how to do it.).
As of march 2017, non-Core EF, i.e. EF 6.1, is no longer being updated. MS will probably solve bugs if they appear, (this was wrong: but don't expect further changes)
New features appeared in 6.2: What's new in EF 6.2, which includes definition of indices with Fluent API, support for Like, support for non-identity DB generated keys, like SEQUENCE and some other changes
Changes on EF Core, former EF7 (as of may 2015)
At this time Microsoft is developing EF 7, but it's also maintaining EF 6.x. The current recommendation is to keep using EF 6 for some time, because EF 7 is not mature enough.
EF 7 is being developed from scratch to overcome the inherited ObjectContext which was posing terrible limitations to implemente new features. But it implements the most widely used DbContext with little changes. So, if you use DbContext you'll have an easy migraiton path to incoming new versions of EF.
However there is a very important change: in EF Core (former EF7) the EDM model dissapears in favor of Code First models. So, if you want to use the technology of today and assure an easy upgrade to new versions, don't use Model First or Database First: use Code First. There are important reasons for Microsoft to have taken this decision: Code First works much better in a team environmet with version control, and allows to work with Migrations. Anyway tou can still see the model in a graphical way (with Power Toools) or use a third party tool to create the model using a designer (several of the current commercial solutions will support this for EF7).
NOTE: Why is much better Code First in team environments? If several team members modify the model it's much easier to merge changes in several code files, than in a big XML file, with lots of lines which defines the model. It's also much harder to understand the changes between versions in this hugh XML file. For medium or big projects, I recommend you to move to Code First ASAP
My application is using a database first EDMX in EF 4. I would like to upgrade everything to EF 6. After getting EF 6 with NuGet I had to make a lot of changes to my classes that are using my EF model, because namespaces have been changed in EF 6. Then I realized, that the code generated by my EDMX does also use the wrong namespaces etc. I'm not using a custom T4 so far.
How would I upgrade my existing EDMX to EF 6.
Thank you.
You delete your old .tt files
You open your edmx file in designer mode (so you can see your model)
Right click on a free space
Select Add Code Generation Item
In the dialog select "EF 6.x DbContext Code Generation Item" (something like this)
Save your edmx and all classes will be generated for you, with the new namespaces and so on
In addition to the answers given here by Rand Random and Dean Oliver, let me mention the following MSDN link, describing general steps for upgrading to EF6. Don't underestimate the manual steps required...
The road map is (see details in the link given above):
Preparation: Install the Entity Framework 6 Tools for Visual Studio 2012/13
Install the EF6 NuGet package
Ensure that assembly references to System.Data.Entity.dll are removed (Note: Installing the EF6 NuGet package should automatically remove any references to System.Data.Entity from your project for you).
Swap any EF Designer (EDMX) models to use EF 6.x code generation. Notes:
If you're getting the message "The Entity Data Model Designer is unable to display the file you requested" afterwards, then click on the link modify in the displayed text message "The entity Data Model Designer ... You can modify ...", which will display the tables. Select all with Ctrl+A, then press Del, then right-click and select "Update model from database", and finally save using Ctrl+S. This will update the model to the latest version using the default T4-Template "EF 6.x DbContext Generator".
If you have used ObjectContext in your project, then you should consider downloading the template "EF 6.x EntityObject Generator". Then right-click in the model designer, choose "Add code generation item", then choose a name you haven't used yet. It will generate the right classes, afterwards you have to remove all old ("*.tt") files and related generated class ("*.cs") files.
Update namespaces for any core EF types being used, i.e.
any type in System.Data.* is moved to System.Data.Entity.Core.*
System.Data.EntityState => System.Data.Entity.EntityState
System.Data.Objects.DataClasses.EdmFunctionAttribute => System.Data.Entity.DbFunctionAttribute.
Note: This class has been renamed; a class with the old name still exists and works, but it is now marked as obsolete.
System.Data.Objects.EntityFunctions => System.Data.Entity.DbFunctions.
Note: This class has been renamed; a class with the old name still exists and works, but it is now marked as obsolete.
Spatial classes (e.g. DbGeography, DbGeometry) have moved from System.Data.Spatial => System.Data.Entity.Spatial
N.B.:
More information about available EF templates can be found here at MSDN.
If you're getting an obsolete attribute warning after upgrading to EF6.x, check out this SO article: How to get rid of obsolete attribute warning?
As well as the steps Rand Random suggested. Remember to Install Entity Framework 6 Tools for Visual Studio 2012 if you are using VS2012. download here
This will ensure that EF 6.x DbContext Generator template shows when clicking Step 4: Add Code Generation Item
I am using an existing database and my normal method is to add a new Entity Data Model and point it to the existing database. If I was to use the EF power tools and reverse engineer to make it 'code first' style what is the advantage of this ?
Both are classes that inherit from DbContext right ? So can someone explain to me what an advantage might be working with the code base over time if I was to use the EF power tools reverse engineer tool instead ?
Code First to an existing database generates your model (at runtime) from your C# classes. Database First stores the model inside of an .edmx file and generates your classes (at design time).
The video Entity Framework Development Workflows gives a good overview. Ultimately, it comes down to whether you want to maintain your model using a designer surface or using C# classes.
It is also worth mentioning that, if you want to use Code First Migrations, you have to use Code First since it currently doesn't work with Database First.
In the Eclipse Modeling Framework (EMF), there are ecore files to define a model. From this model code (and other things) can be generated. This generation step is described by an "EMF Generator Model". Now my question is, why this file is called "model" instead of "configuration" or something like that. In my opinion, it does not model anything, but it describes a generation step...
While the other answers are perfectly correct, there is one additional difference between a "model" and a "configuration". All EMF models (including this generator model) can be modified, transformed and so on by every already available EMF tool (because they all use the same meta model).
This is a huge difference compared to the situation that the configuration can only be read by another tool, if it knows the exact format of the configuration serialization.
So you can create an UML diagram of the generator model, you can use it in a model based graphical editor, you can transform it using model-to-model transformation plugins, you can put it into EMFstore, ... without any of these tools having been prepared specifically for that model.
The current implementation of EMF was created with a bootstrapping-approach.
At first, the model that describes the data that is stored in ecore and genmodel were written by hand. As soon as EMF was stable enough, these were modeled and generated with EMF itself.
This means, the ecore and genmodel are in every way a EMF model.
This is similar to how many compilers for new programming languages are developed. The initial implementation has to be written in a second language, but as soon as the compiler is complete, you can use the new language to write a new implementation, add features, and then use the binaries of the previous version of the compiler to create the next.
From the creator of EMF, Ed Merks:
After all, EMF's generator model generates both the Ecore model and itself, so we're not actually in a position to delete our generated code. We need it to bootstrap the environment. It's prickly problem.
http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html
Actually the genmodel as well as the ecore files are also EMF models technically speaking. So this is not a surprise that it is called this way.
In fact you have to understand that EMF allows to describe any kind of structured information. So it can be used to describe your own semantics as well as describe code generation configurations or even describe itself (ecore).
HI,
I'm a bit lost with Entity Framework ...
Here is the context : Desktop Application (C# / Winform)
VS 2010 (SP1), SQL COMPACT (4.0 for identity), ... for now EF 4 (default version)
I've just started a new app and i've thinking of using EF because it seems that it's a quickest way to design both model and database (i know that it's not the best way but my project is not critical).
building the model with graphic designer is very convenient, i can easyly build the sql compact schema' and i can access model class directly.
But i need to add some feature to my model class (overriding ToString for example or some basics functions), so it seem that i need to make POCO classes.
But the problem is after generating these classes, how can i update these without losing added code , what's the best way to doing that ? partial class ?
Moreover, it seem that EF dev are focusing on Code First, so does it mean that Entity Model are already deprecated ?
EF generates partial classes, so you are right - in order not to lose the extra code you add, you need to create separate files and use the partial class feature. Those files won't be re-written once the model is saved.
Moreover, it seem that EF dev are
focusing on Code First, so does it
mean that Entity Model are already
deprecated ?
No, it's not deprecated. Using Code First is just a matter of preference, but you can feel free to use the EDM - it's not going anywhere.