We have to maintain a very old application.
There is an old part (all data access is handled with stored procedures) and since my predecessors took over the application, they started to build a new part for the new requirements which uses entity framework 6.
Now the customer has a new requirement that needs access to one of the tables for which there isn't an EF-model yet.
Is there an easy way to automatically create an EF-model from an existing database table? (I only want this one table, not the whole remaining database!)
Do you know of any tool that can achieve this or do I have to write it by hand?
Thanks in advance
I use EF Power Tools which is a plugin for Visual Studio.
Download here
With the plugin, you can reverse engineer your database in order to create your objects and mappings in your application. Despite the fact that it will save you a lot of time, note that it is not perfect. You might want to review your indexes and relationships as some were missing in my case.
To Reverse engineer your database, it's as simple as this:
The Reverse Engineer Code First command is used to generate the POCO,
mapping (configuration), and derived DbContext classes that are based
on an existing database.
Right click the project and select Entity Framework –> Reverse
Engineer Code First.
Enter the information about an existing database
based on which you want to reverse engineer Code First.
You can check this link from Microsoft for a complete example:
https://msdn.microsoft.com/en-us/data/jj593170.aspx
IMPORTANT: As of Entity Framework 7 (not released yet), only the Code First approach will be used. You might want to consider this before choosing another approach like Model First, for instance. You can read more about: EF7 - What Does “Code First Only” Really Mean
Open the Entity Data Model (edmx) file (edit: or create one if you don't already have one), right click on the design surface in a blank area, and select "Update Model from Database".
Select the proper connection string if prompted, then choose the "Add" tab, and drill down to the tables in your database you want to add and put a check mark by them. Click Finish and you're done.
Check out the EF power tools plugin which give you context menus for Reverse Engineer Code First as well as other code generate options
https://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d
Can't you just create an EDMX and only have it select the tables you want it to point to instead of the whole DB?
Look at Generate From Database in this article
https://msdn.microsoft.com/en-us/data/jj206878.aspx
Related
I have to create an application in MVC 5 using EF6. I have already created the schema for the database in SQL Server 2012 and now I want to query this in my app.
The workflow that seems fit is Code First with Existing Database and I have tried to follow below resources but they are a little confusing to me as I am a beginner.
Is there a way I can still use my DB schema in SQL server and go ahead with Code First approach using generated data models from DB.
http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
http://www.asp.net/mvc/overview/getting-started/introduction/getting-started
Yes you can reverse engineer code first from existing DB schema. Here you can find instructions how do do it. Since you already created your DB schema you can start from point 3. Reverse Engineer Model.
This process will create for you a DbContext, POCO classes for the tables you selected in the wizard and the mappings. You can use it to query your DB.
When your DB schema changes in the future you can either regenerate POCO classes again or simply edit them by hand (if column type changed simply change the property type, if new column was added add new property to your class). Most devs use reverse engineer code first from existing DB only as a starting point when they need to target existing legacy database. After initial creation all future changes in schema are reflected by manually editing the classes that were originally generated by the tool.
I have a solution which uses Entity Framework model first approach.
The problem I am facing is that whenever I change something on a table, add a column or change a relationship,I right click and go for "Generate Database from Model", which re-generates ALL the code for the solution even if I just changed one table..and that generated code is useless for a production database since it drops every table and then re creates them..
I am wondering, isnt there be an option just to generate the T-SQL with the changes I made ? Otherwise model first would be useless after your app goes into prod.
I am using entity framework 5.0
Personally, I would suggest you to use Red-Gate SQL Compare when you need to sync your databases at Production environment.
This tool helps you to compare and synchronize databases using sync scripts without losing data (it will alert about if so) and its UI is just awesome.
Could someone explain the concept of Migrators (specifically fluentmigrator)?
Here are the (possibly confused) facts Ive gleaned on the subject:
Is it a way to initially create then maintain updates for a database
by way of versioning.
The first migration (or initial version of the
database) would contain all the tables, relationships and properties
required (done either fluently or using a chunk of sql in a script).
When you want to push a change to a database, you would create a new
migration method (Up and Down), something like add a new table or modify a field.
To deploy one of these migrations, you would use a
command line specifying the dll containing the migration, the
connection string and the required version.
If you had a rather complex set of data models, wouldn't it be rather difficult and time consuming to create a migration definition for all of that?
I know with nHibernate/fluent you can easily generate tables for a database without having to define anything other than the models and map files. Is there a way to make this configuration compatible with the Migrator/Versioning?
When nhibernate/fluent is in charge of generating a database, I do not necessarily need to define every thing aspect of the tables. Its done either via convention or via the mapping files. With the migrators I would need to define this level of detail?
Lots of questions here. I'll answer the questions with a focus on FluentMigrator.
Is it a way to initially create then maintain updates for a database
by way of versioning.
FluentMigrator is a way to version control your database schema. Everyone does it in some way. Either manually, with sql scripts, with a tool like SqlCompare or a Visual Studio Database project. All these methods are easy to mess up. It is so easy to make a mistake when releasing a new version and cause the system to crash. Migrations is a better way to handle this.
FluentMigrator allows you to define a change to the schema as code and this is usually checked in to your source control with the other code changes. Meaning that you can say version 1.XX of your system should have version 123 of the database. It means if you roll back your code to the previous version you also know what version of the database to rollback to as well.
It can be used both to create the database schema from the beginning or to start with version control of the schema for an existing database.
A Migration is a way to describe a change to your database schema. FluentMigrator creates a VersionInfo table and stores the unique id (version number) of the Migration after is has been applied.
For example, if I have two Migrations one with Id 1 and one with Id 2. If then I execute the first Migration then Id 1 will be stored in the VersionInfo table and I can look there and know that the version of the database is 1 and that version 2 has not been applied yet.
Being able to know which version the database schema is very useful when pushing changes from Test to Production or if you have multiple copies of the database in Production. For example, I have a customer with offices all around the world and each office has their own copy of the database and all of them are on different versions. Without knowing the database version it would be very difficult to update them safely.
Most of the time I do not need to actually look in the VersionInfo table, FluentMigrator handles this automatically. It compares the assembly with Migrations to the VersionInfo table and figures out which changes have not been applied yet and then executes those.
The first migration (or initial version of the database) would contain
all the tables, relationships and properties required (done either
fluently or using a chunk of sql in a script).
The starting point is up to you. You can have a first migration that is an sql script that you have generated from the current database. You could could also use one of the contrib projects like FluentMigrator.T4 to generate a Fluent Migration. Or you could just decide that the existing database is the starting point and save a copy of it to be able to restore it as version 1.
I have introduced FluentMigrator to a lot of legacy databases without any major problems.
When you want to push a change to a database, you would create a new
migration method (Up and Down), something like add a new table or
modify a field.
Yes, Up is used to apply the change specified in the Migration and Down rolls it back. So Up could be to create a table and Down could be to drop the table.
To deploy one of these migrations, you would use a command line
specifying the dll containing the migration, the connection string and
the required version.
There are three runners available to execute migrations. The command line runner, the Nant task and the MSBuild task. There are usually executed as part of a build script.
The MigrationRunner class can also be used in code. You might do this if you wanted to build your own runner or if you have other needs (like building databases dynamically or automatically updating the database if a new migration is added.)
If you had a rather complex set of data models, wouldn't it be rather
difficult and time consuming to create a migration definition for all
of that?
I have mostly answered this already. It is usually quite easy to generate an sql script for a database. For Sql Server it takes less than a minute to generate the script even for large databases. This script can be saved in a .sql file and executed as the first migration using the Execute.EmbeddedSqlScript expression. It works a treat.
I know with nHibernate/fluent you can easily generate tables for a
database without having to define anything other than the models and
map files. Is there a way to make this configuration compatible with
the Migrator/Versioning?
At the moment, there is no such integration and in practise I, at least, don't miss it. There was some discussion about connecting Fluent NHibernate and FluentMigrator but it would be a lot of work. It would enable scaffolding to generate changes to the model like EF Code First migrations do. It's not on the roadmap at the moment however.
When nhibernate/fluent is in charge of generating a database, I do not
necessarily need to define every thing aspect of the tables. Its done
either via convention or via the mapping files. With the migrators I
would need to define this level of detail?
Yes, you would need to define at that level of detail. FluentMigrators' migrations are a DSL (own little language) for defining schema changes that are translated to sql. You can write sql directly as well using the Execute.Sql expression. Entity Frameworks migrations have that sort of integration which has both advantages and disadvantages.
Check out the wiki or one of the tutorials here, here (part 1) or here (part 2) for more help getting started.
Let's say you have a database that is currently in use. It has one table that contains some information about Customers.
And let's say that you want to create an application around it. You need to use the Customers table in your program, but you also need to add some new tables, possibly connected to the Customers. For example, you need to add an Orders table that has some association to the Customers table.
I have started to learn Entity Framework. I have learned a bit about "Database-First" and "Model-First" data models. But the situation is, what I want to do doesn't fit into any of these categories. I neither have a completely empty database, nor a finished database schema that can directly be used in the program.
What should I do? If I go with "Model-First" and design my entities using the Visual Studio Designer, can I just use it to create the relevant part of the database schema?
Go with Data-first, THEN go with Model-first. You don't have to pick... use the data-first wizard to generate EF for your existing table, then use the designers to create additional objects, then sync that back to your database. The concepts of model-first and data-first only applies to the initial creating of your EF stuff - anything you do after that can by synced in either direction.
This shows how to put database changes back into your model after it's created - you can do the other way too, but I can't find that article - all the new videos and crap are hard to navigate - you may be able to find it.
http://msdn.microsoft.com/en-us/data/jj206878
After all, the framework wouldn't be very useful if it locked you into never being able to update anything. Right?
The more development into your project, the more Database-First it'll become, so I suggest you to go with Database-First right now and then extent your EF entities and then implement/fake/mock the missing pieces
If you haven't read about TDD, it's time to do so now. It'll save a ton of time down the road especially when working with an ever changing data model.
We are upgrading an old VB6 application which sits on a SQL Server 2005 database, to an Entity Framework solution. The database remains the same, except - we're adding a new table. Is it possible with Entity Framework, to maintain the existing structure, when it gets installed on a client PC - and just add one new table?
Is this how Code First will work? Can I be 100% certain that no other tables will be modified?
i don't think, the effort is worth it to switch to code-first if you have an existing database and want to add only one table.
it is possible to map code-first classes to an existing database (reverse engineer code first). actually, i'm not very experienced with that workflow, but i know you can. You have to deal with a lot of manual mapping (with DataAnnotations or Fluent API), so in your case i would recommend to use the Entity Framework Database First workflow, since adding a single table saves you a lot of work.
this link has some useful information: Arthur Vickers Blog - Don't use Code first by mistake
You have two options, use a database editor such as SQL management studio to create the table which you can then map to a ef entity, or use migrations for ef which will let you update your database via ef.
Take a look at the migrations tutorial here: http://msdn.microsoft.com/en-gb/data/jj591621
I am using the database first approach, since a database developing team is doing the changes I require in the database on the SQL server for me.
Hence, I have to update the EDMX whenever the schema in the database changes.
Note: Changing one single table directly does not work for me, because VS doesn't always detect the changes right (for this issue, here are some details in SO if you're interested).
Hence, I am using the following workaround (regenerating all the tables):
In VS 2012, open the EDMX file by double-clicking on it. The graphic representation of the tables is shown.
Left-Click into the EDMX designer, then select all tables by pressing CTRL+A. Then, remove them by pressing DEL.
Right-Click into the EDMX designer and select "Update Model from Database ..." in the context menu.
The Update Wizard opens. In the "Add" tab, check "Tables", and depending on the requirements, check "Pluralize or singularize generated object names", "Include foreign key columns in the model" and optionally "Import selected stored procedures and functions into the entity model". Usually, I am using the "Pluralize..." and "Include foreign key columns..." options.
Click Finish. Now Save by pressing Ctrl+S.
That workaround works fine for me, and requires just a minute to update the model reliably.