0

Please I have a question and I have searched extensively on Google but couldn't get concrete answers.

I have a project. I already used the Identity framework and by this, it generated the database using code first.

I intend to use database-first for subsequent tables.

My questions are below:

  1. Can I generate the database first such that it uses same DbContext as the code first entities?

  2. Will they have separate connection strings?

  3. Do I have to continue using code-first, or can the two approaches be combined in a project?

I am actually new to Entity Framework.

Thanks

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
mantics
  • 9
  • 6
  • If you create your model classes such that they match the database, either by convention or annotation, then it will work. You don't need to use code first Migrations but it's probably a good idea. – Crowcoder Jun 06 '20 at 11:18

2 Answers2

0
  1. Can I generate the database first such that it uses same DbContext as the code first entities?

Yes, you can. you can generate the database schema by code first, then turn to database first, when you use database first to generate the DbContext, it will follow the rules that you generated by code first.

  1. Will they have separate connection strings?

No, I guess that you have to do it manually.

  1. Do I have to continue using code-first, or can the two approaches be combined in a project?

It's not a good practice to use both code first and db first in a project, so I would recommend code-first only.

For further information, you can take a look at this

Allen Chen
  • 228
  • 1
  • 8
0
  1. Can I generate the database first such that it uses same DbContext as the code first entities?

No you can't, assuming you're using ADO.NET Entity Data Model / .edmx to import your database tables you generated into your project.

The reason is, when you use Code First, your connection string in the web.config will look something like the following:

<connectionStrings>
  <add name="YOUR_IDENTITY_CONTEXT_NAME" providerName="System.Data.SqlClient"
    connectionString="Data Source=xxx; Initial Catalog=xxx; User Id=xxx; Password=xxx;" />
</connectionStrings>

But when you use .edmx to import tables into models/classes into your project, it won't see your existing connection string you had with Code First. Instead, you will have to create a new connection string, which will look like the following:

<connectionStrings>
  <add name="YOUR_DATABASE_FIRST_CONTEXT_NAME" providerName="System.Data.EntityClient"
    connectionString="metadata=res://*/xxx|res://*/xxx|res://*/xxx;provider=System...." />
</connectionStrings>


  1. Will they have separate connection strings?

Yes, they will.


  1. Do I have to continue using code-first, or can the two approaches be combined in a project?

It would be great if you can use Code First all the way through, but if you can't, there are other ways you can mix Code First and Database First approach:

  1. Just use 2 separate connection strings

    I typically name the Identity DbContext AppIdentityDbContext, while the data context generated by .edmx just AppDbContext.

  2. Use different ORMs other than Entity Framework

    You don't have to stick with one ORM in a project. You can use Entity Framework for identity stuff, and use something else, such as Dapper, for reading.

David Liang
  • 20,385
  • 6
  • 44
  • 70
  • David Liang, Thank you for the insight and thorough answers. However, I want to ask also, is there any implications, maybe security or performance to be having two connection strings? – mantics Jun 08 '20 at 14:09
  • @mantics: I don't think so.You need to securely encrypt and store the connection strings after all, regardless there is just 1 or more. The only "drawback" I can think of with having 2 connection strings pointing to the same database is that you might have to keep them in sync, if there is anything changed to the connection. – David Liang Jun 08 '20 at 18:21