Trying to grasp the big picture here. This is a Web Forms project using Identity + EF for user management. The default project contains IdentityModels file which suggests that I should add custom properties to ApplicationUser class and then use migrations to update my database. I did that and the database was generated/updated. So far so good.
Now I add a new EDMX to my project and import all my DB tables into it. This obviously brings in Identity tables into the diagram as well, which is good because I'll be adding my business domain tables and linking them to Identity tables through the model and then use migrations to update my database. Here are the questions and problems I face:
Am I using Code-First or Model-First, or a mix of both (Does such a mix work)?
Do I have more than one model in my project, namely the default Models file and the one generated by EDMX?
If I have two models, which of the model classes correspond to AspnetUsers table; the default ApplicationUser class or the AspNetUser class generated by the EDMX? I mean which of these classes will be used by migrations to update my table's structure?
Adding new properties to my ApplicationUser class doesn't seem to have any effect when I run Add-Migration and Update-database commands. It generates empty Up() and Down() functions.
Adding a new property to an EDMX entity and then trying to send it to the database through migrations throws error saying that the new property doesn't have a mapping column. Now that's obvious I know, but then how does Model-First approach send changes to the DB?
I know these are more than one questions, but they are tightly related and anyone trying to get a start will most probably face all of them, so I've gathered them in one place for future readers.
In my understanding using both EF Code-First and Model-First can add a burden of keeping them in sync. You may want to check the following sample project which uses only DbFirst approach:
https://github.com/kriasoft/AspNet-Server-Template
OK. After working with the project for a few days, I have figured out a few things that might be helpful for future readers:
As #Konstantin said, as a general rule, you should not use both code-first and model-first approaches in the same project. Personally I prefer database-first over both of them, i.e. create a database design and then import it into my EDMX model. I can then make changes to my DB design later and use "Update Model from Database..." command to refresh my model.
AFAIK, migrations cannot currently be used with EDMX models. These only work with code-first approach.
ASP.NET Identity will automatically create all required tables in your database when your website runs for the first time. You simply need to correct the connection string in your web.config file.
You should generally avoid bringing in Identity tables into your EDMX, but if you really need to do that, do not make changes to these entities through EDMX. Simply use ApplicationUser class in IdentityModels file to add custom properties to your user class.
Related
I am building a .NET Core 6 web app using individual authentication.
The default identity tables are stored on the same DB as other custom tables. Some of the tables and columns will be updated from time to time in a DB-first manner.
I can manually add entity Properties in the OnModelCreating method of ApplicationDbContext, but that is quite tedious, there isn't a great way I know of to keep track of the diff between the db and the entites, and I risk mismatching types.
I can quickly scaffold individual tables into my ApplicationDbContext. I can scaffold new entities or use the force flag to overwrite existing entities, but as far as I can tell, it rewrites the entire file.
Assuming I have an AspNetUser class that inherits from IdentityUser, is there a way to ignore the properties defined in IdentityUser when scaffolding?
Migrations work nicely because they keep track of just the changes since the last migration, but any changes to the DB are required to be made in the DB first for this project.
Using EF Core 6 is there a way to update extended entities in a cleaner way?
Is it best to create new related tables to contain any data specific to a user (such as FirstName, LastName) and avoid generating all new definitions for default identity properties?
Is it best-practice to just ignore the IdentityUser class and adopt the generated AspNetUser class with properties identical to those in IdentityUser and any additional properties when scaffolding to update entites with DB changes?
Thanks for the guidance!
I have been asked to write a web site that will use an existing SQL Server database. The database was designed to work with another application, and so I can't make any potentially breaking changes to it.
Unfortunately, the database does not contain a single relational link, each table is standalone.
I know you can use EF commands to scaffold a database and create entity classes, but I would like the code to know the relationships that should exist between the tables.
I thought about scaffolding the database, then modifying the created classes to include the links, but I'm not sure if that would allow EF to load related entities. Also, as I will need to add some new tables to the database, I'm worried that EF will try and create those links when I do the migration.
Is there any way to do this?
I have several tables in my SQL database that are generated from POCO objects using Code First and Migrations. I also have several tables in a different Schema that are created outside of the project by another process.
How would I combine these two sets of tables in one DB Context without losing the code first migrations features and without overwriting the existing tables in the second Schema?
Pretty simple actually. Create or reverse engineer the other schema POCOs. Add any fluent config needed (or get it from reverse engineered class)
public virtual DbSet<OtherSchemaTable> OtherSchemaTable {get; set; }'
...
Create a new migration to replace your snapshot, but not update the database:
add-migration OtherSchemaAdded -IgnoreChanges
update-database
Now you can continue on with migrations for your tables and reference the other schema. As long as you don't change other schema models you are OK. If you are worried about that, another option is to use database views to reference the other schema tables (assuming no updates needed).
That means you have to take over the migrations process. I am not sure the EF team currently supports exempting certain entities from the Migration process (at least not directly). Perhaps you can the entities in question with a custom Attribute that you define. Then override the default SqlGenerator to ignore entities with this Attribute so CREATE TABLE statements are not issued for them.
I'm working on an ASP.NET project. I migrated my database named "youbay" with
reverse engineering. It worked. My database contains tables (picture, user, product...) but when I try to change something on the code and then update my database it with code first other tables are then created named youbay.picture,youbay.user...
What do you concretely mean with RE? Creating ASP.NET Models by guessing the mapped .NET types of the table scheme? Maybe your db-structures are a bit different from the ones EF would genereate itself, so that EF will see a conflict. Or EF keep track of the changes itself, so he isn't touching the tables because he won't recognize that he created them.
Whatever happened, it seems like your way of migrating was not very clean. You should tell EF use an existing database like explained here. This will prevent conflicts and also save work/time, because EF will automatically generate your models based of the database-scheme. So no RE is needed.
I have added added Entity Framework to my project and selected Code first from database when creating my models. But the problem is, i couln't find how find how to update existing models and add new models to my project when i make changes on database.
It is very straightforward. Switch on migrations, change/add you classes, create a migration and update your database. See here for example. There are plenty of other sources.
When you change your DB you can run the EF generation again but it will overwrite the existing files so you will lose any changes. If you want to maintain code outside the generated files then you can use partial classes. Or alternatively just code them by hand after the initial auto generation, it's quick once you get used to it! :)