Aspnet MVC database first or code first

Asked

Viewed 100 times

4

I have an Aspnet MVC 5 project in which I will use Owin and Identity, I needed to customize Identity (attributes and relations) to meet my needs, but I already have all the tables of the database "ready" (unpopulated), in these existing tables I will create relationships for my Aspnetusers Identity table. Is that the problem that is wrong? What are the problems in doing this? I feel like I’m mixing databasefirst with codefirst and I don’t really know if this is right or not, what problems can arise when I have to fiddle with the Fist code of the identiy classes? What are the problems when moving the columns of my ready-made database created via databasefirst?

  • I don’t see any problem in doing this, it uses codefirst for everything (I prefer at least) and changes the connection string from Identity to that of your database, it will already create everything there. (If you used the default template just do this) from there is to make relationships.

1 answer

2

That’s the problem that’s wrong?

No. Identity is designed to work with a nearly complete level of customization. Not only is it possible to define more User relationships with other entities, but even to change the table name in the database.

What are the problems in doing this?

To my knowledge, there is no problem in relating users with other entities of your system.

I feel like I’m mixing databasefirst with codefirst and I don’t really know if this is right or not, what problems can arise when having to move Fist code of the identiy classes?

If I understand, apparently you want to take advantage of a database that already exists with ASP.NET Identity. Then I would say that can be problematic. Explain:

ASP.NET Identity implements some features that your existing bank will hardly ever have, such as handling passwords. Unless your bank has exactly the same information would work smoothly, which is very difficult because other frameworks do not implement the same encryption scheme.

In this case, it is best to implement a schema of your own and not use Identity.

What are the problems when moving the columns of my ready-made database created via databasefirst?

It depends on several factors. A legacy system could stop working, for example.

For existing databases, it is not recommended to let the Entity Framework manage the database. The Database First does not manage the database by design.

  • Yes I already have a database "done" but I will exchange all the permissions and users to work with Identity. One problem I have now for example is that I don’t know how to use the same database connection, both for the Identity classes I created via codeFirst and for the classes created by VS via Databasefirst. I haven’t used transactions yet, but I think I’ll have problems. How could I use the same connection ?

  • You better wear the same Connection string to Identity and bank, creating the new tables that ASP.NET Identity needs to work. This can be done by creating a new project with ASP.NET Identity on top of an empty database. Then you make a script and run this script in your old database.

  • Thanks for the quick response, but I didn’t get it right... I have a custom Identity, with more relationships and properties. What I would do is create a new project and only create my custom identity. Generate an SQL of this Identity and place via databaseFirst in my real project?

  • ...and put via script in your database. Database First considers that it is the user who takes care of the database, not the Entity Framework with Identity.

  • Okay, just one more question: having created via sql script these Identity tables in my database and then created their respective classes via ADO Entity data Model as I would extend from the Identityuser class, to have all the benefits of Identity? Is that what you proposed or am I mistaken?

  • That’s exactly what.

Show 1 more comment

Browser other questions tagged

You are not signed in. Login or sign up in order to post.