I have to create some new entities in a new or existing database using Entity Framework that will need to interact with some legacy tables and I'm wondering what the best approach is here. I was hoping to use Code First with migrations.
For example, say I have an existing populated Person table and I need to create a Animal table that will contain a PersonId foreign key to reference the existing people.
As far as I can tell these are my options:
Create a new DBContext (for a new DB) with an DBSet<Animal>, using code first migrations and POCO entity classes. Ran into problems with setting up the foreign key pointing to another DB.
Create a new DBContext (targeting the existing DB) with DBSet<Animal> and create some kind of POCO wrappers around the existing table. I'm not sure if this is possible - I tried something like but when applying the migration EF tried to create the Person table. I assumed this would map to the existing table instead of creating a new one:
[Table("Person")]
public class Person {
Use Database first with the existing DB and create the tables in the existing DB but then I lose out on using POCO and migrations with my new entites.
Are there any better options that I'm missing or should I go ahead with using Database first?
You can use EntityFramework Reverse POCO Code First Generator.
Reverse engineers an existing database and generates Entity Framework
Code First Poco classes, Configuration mappings and DbContext.
This generator was designed to be customisable from the very
beginning, and not fixed and rigid like other generators. Go and play
with the settings in the .tt file, that's what it's there
for.
Here is the link : EntityFramework Reverse POCO Generator
Related
I have a database with some tables for school related project and I have a model with EF 6.0 SQL-first approach. I need to update the database with a new table & update an existing table with a new column. The twist is: I don’t have any *.edmx file.
How can I update the model without it? If it is impossible, then how can I generate *.edmx without interrupting the existing model?
Entities are essentially POCOs, so you really just need to update your schema and update the entity classes to match. For new entities if the project is not using an edmx then it should either be using classes extending EntityTypeConfiguration or setting things up with the modelBuilder on the OnModelCreating event in the DbContext.
EF can resolve most general mappings using convention, so adding a column to a table usually just means adding the property to the entity. Mapping only comes into play when you want to change a columns naming, handle type casting differences, or use identity/computed columns. For new entities it can also use convention, but commonly there would be config used for the Table name, PK name, and things like Identity columns, plus navigation properties for related entities.
I am building an Ntier application with EntityFramework c#.
I am adding an Entity Data Model in my Data Access Layer with code-first approach from existing database.
Some of the tables of my db weren't included because they don't have primary key. I have seen some ways to work around this problem, modifying EntityFramework's edmx to force the mapping to the database, disguising some field like a key. But I am not using the .edmx, since I can't use automatic migrations with it. I only generate POCOs from my existing database and then go on with code first migrations.
Is there a way to force Entity Framework to generate a POCO for those tables without primary key ? Some only have one entry and really don't need PrimaryKey
In the end, I just wrote my own POCOs for the tables that weren't included.
I used an attribute [KEY] above the property i wanted to act like key. I added DbSet lines in the DataModel and EF did recognize them in my database.
I didn't want to generate primary keys because my boss didn't want, and thats a reason good enough. :) Hope the best for you thx for answer
It is possible to generate a POCO class for one selected table in entity framework.
There are few tools that does that, but it does generate for all the table,
The primary reason i am asking this is to generate a POCO class for a single table, and add attributes to it manually, and the all i need to do is to attach it to DbContext as a property :).
As for example using Package-manager, they way it is done to add migration
generate-poco TableName FileName.cs
You can use the ADO.Net wizard to generate the POCO classes for you from the database. The wizard will generate one partial class per table with properties that match your field names. Here is what I've done in the past when I wanted to add a new large table to an existing code first context.
Add->New Item -> ADO.Net Entity Data Model
Move the generated POCO classes to some other folder (and edit the namespace)
Delete the rest of the extra stuff (I.e the .edmx file and generated context)
Add the DBSet to 'your' DBContext
If you are using EF migrations
add-migration
update-database
There are a lot of extensions for visual studio for that.
EF 4.x POCO Entity Generator for C# Free (try this one and you only need to map the table)
Assumptions
Using EF 6.1, MVC 5, VS 2013, C#
I have an existing database model designed in Toad DM for SQL Server and it's very important keep it always updated
Steps and Notes
Using ADO.NET Entity Data Model I chose Code First from Database (new feature in EF 6.1) to generate the models. Note: Model classes and DbContext class generated successfuly but NO .edmx or .tt file was generated.
Next I added a new scaffold item: MVC 5 Controllers with views, using Entity Framework. Note: Success, controllers and views generated
Question
From now on I don't want to use Code First to update my database. Instead I want the models to be updated based on database changes. What to do next? If I don't have an edmx file will I not be able to update my model classes from the database?
The Entity Data Model Wizard's Code First from Database does an excellent job creating your entity classes, as if they were created in the Code First style. What you are asking is if there is any way to keep these classes up-to-date as your database changes, similar to the EDMX style "Update Model From Database". From what I've researched this is not possible using the built-in tooling. However, here is one workaround that I've found useful:
Let's say I have database with a product table and customer table. Originally I created a StoreDBContext class, and selected product as one of my objects. Now I want to add the customer table as a new entity to the existing context. Here's how to do this using the Code First Wizard:
Create a new Entity Data Model, call it StoreDBContextTemp or whatever
Choose the code first from database wizard option
Select customer as an object to add (just customer) & complete the wizard
Open the newly created context file, StoreDBContextTemp.cs, and copy the virtual properties of your newly added entities:
public virtual DbSet<Customer> Customers {get; set;}
Paste these new properties into your Original StoreDBContext.cs dbcontext class.
Delete StoreDBContextTemp.cs, and remove the connection string for StoreDBContextTemp in app.config/web.confg etc.
You can now use Customer on the StoreDBContext class
If you add or remove tables you will need to manually adjust fields, but at least you won't need to hand write dozens of properties each time a new table is added to the model.
One more option is just delete the auto generated classes from the project and once again generate them.
While following this approach only thing we need to make sure that is we should give the same name for the data model(class name which inherits from DbContext ) as the previous one.Data model name is highlighted in below snap
Three things.
There's no .edmx when you use Code First.
If you use Code First Migrations you would have to write first the code and after that migrate the changes to database. This helps you to have much more organized you code with no generated code which is an advantage.
There's a plugin in Visual Studio for doing contrary. Entity Framework PowerTools allows you to select the database and map it to objects.
https://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d
The best solution to me is deleting the model and recreate updated one with the same name, keeping in mind two points:
Personal extension methods implemented for the model;
Possible manual relationships between tables added to the model because of not setted up in the phisical db.
My personal solution:
Move all extension methods to another partial class that won't be overrided;
Insert all added properties of an entity to another partial class;
Keep track of all manual relationships in an help file, so you can add them again being sure not to loose anything;
Delete the old model and recreate one new with the same name and update it with the manual relationships of point 3.
I have a new project I am starting and I would like to use entity framework 6 code first to handle the database portion. The problem is, I do not have permissions to create a new database on the server I need to use. Because of this, I would like to create a new schema in an existing database and then have entity framework only interact with that specific schema. There are many other tables in other schema in the database that are related to other projects (none of which make use of entity framework in any way) and entity framework needs to leave them alone when it is creating/dropping/modifying tables related to my project.
Is that possible? If so, how do I go about setting that up?
It turns out this is actually pretty easy using EF6! In your context just override OnModelCreating and add
modelBuilder.HasDefaultSchema("schema_name");
before the call to
base.OnModelCreating(modelBuilder);