locked
Why do some professionals prefer ef core Code first approach (which I couldn't) RRS feed

  • Question

  • User283528319 posted

    hi all,

    as an old desktop app programmer, I chose the way I am used to and db first approach

    I feel like I am at home when I use it

    but I watched some pros strongly recommend code first.

    why? what do you say? are they right? and will I be sorry in future to not get used to code first.

    Friday, August 2, 2019 7:00 AM

Answers

  • User-821857111 posted

    If people want to practice Domain Driven Design, they will start with code rather than a database. So it's right for them. Otherwise I don't think it makes much technical difference whether you start with a database or with code. Once you have started, you need to decide what your strategy is going forward in terms of keeping the model and database in sync. I recommend migrations, which means that you end up adopting a code first approach. You could just make changes to the database and then regenerate the model classes each time, but this means that you can't add annotations or any custom code to your code classes or your context class, because they will get overwritten each time.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 2, 2019 8:52 AM

All replies

  • User-821857111 posted

    If people want to practice Domain Driven Design, they will start with code rather than a database. So it's right for them. Otherwise I don't think it makes much technical difference whether you start with a database or with code. Once you have started, you need to decide what your strategy is going forward in terms of keeping the model and database in sync. I recommend migrations, which means that you end up adopting a code first approach. You could just make changes to the database and then regenerate the model classes each time, but this means that you can't add annotations or any custom code to your code classes or your context class, because they will get overwritten each time.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 2, 2019 8:52 AM
  • User1120430333 posted

    hi all,

    as an old desktop app programmer, I chose the way I am used to and db first approach

    I feel like I am at home when I use it

    but I watched some pros strongly recommend code first.

    why? what do you say? are they right? and will I be sorry in future to not get used to code first.

    You don't have to use code first. You can use what is called database first in EF Core too. I am from the old school and like doing database administration the old way using a DBA utility tool like SSMS. I am not into the EF core migration stuff. With DB first, you can point the model creation to  a staging folder to not wipeout the existing model and then copy /paste changes into the existing model. But usually, I just go into the existing model and make the changes manually. It's not that hard once you see what is going on. Just make sure that the deployed database schema and the model are in sync, like you had to do with EF6 DB first.

    If you're like me, who wants to make the model classes by hand? Even making one class is too much.

     

    Friday, August 2, 2019 10:05 AM
  • User283528319 posted

    If people want to practice Domain Driven Design, they will start with code rather than a database. So it's right for them. Otherwise I don't think it makes much technical difference whether you start with a database or with code. Once you have started, you need to decide what your strategy is going forward in terms of keeping the model and database in sync. I recommend migrations, which means that you end up adopting a code first approach. You could just make changes to the database and then regenerate the model classes each time, but this means that you can't add annotations or any custom code to your code classes or your context class, because they will get overwritten each time.

    that is a good point.

    but I don't use any annotations :)

    Friday, August 2, 2019 12:19 PM
  • User-821857111 posted

    If you're like me, who wants to make the model classes by hand? Even making one class is too much.
    If you're like me, who wants to make the database schema by hand? Even making one table is too much.

    It kind of works both ways, whether you choose to start with the chicken or the egg. That's why they support both options.

    Saturday, August 3, 2019 8:46 PM
  • User1120430333 posted

    DA924

    If you're like me, who wants to make the model classes by hand? Even making one class is too much.

    If you're like me, who wants to make the database schema by hand? Even making one table is too much.

    It kind of works both ways, whether you choose to start with the chicken or the egg. That's why they support both options.

    An ORM is not a database administration tool. Yeah it is fine the migration stuff with someone that has  basic DBA  skills in their background. Now of days,  it seems that developers don't even have the basic DBA skills to develop against a relational database, something they administered manually from the start. So when the migration stuff doesn't go as planned, they are bewildered and stuck, because the ORM acting as a DBA tool is robbing them of the basic knowledge they should have out the gate as they use the crutch..

    Most developers now of days don't know what a DBA tool like SSMS is if it ran over them and backed-up and ran over them again. They install an express version of a database and they don't have a clue on how to configure it, but some how they can use the ORM DBA stuff, which gives them no clue as to what is happening basically with DBA and go on, which is short-sheeting them in basic knowledge and they don't even know it.

    It's sad it really is sad.

    Sunday, August 4, 2019 10:28 AM