locked
Moving from EF db First to EF Core RRS feed

  • Question

  • User-401080925 posted

    Hi

    I have a little app using EF db first and I want to move it to  EF Core.

    I've used my models classes generated previously.but I got some errors:   

    The entity type ... requires a key to be defined

    or

    SQL error Column unknown MYTABLEID 

     (I have MYTABLE and column ID  but not the table MYTABLEID )

    What configurations should I have to do for EF Core because  my db provider doesn't yet support scaffolding.

    thanks

    Thursday, October 26, 2017 12:03 PM

All replies

  • Thursday, October 26, 2017 12:15 PM
  • User-401080925 posted

    Hi.thanks for your answer

    So I have to use fluent-api to specify for all entities PK and FK?

    Thursday, October 26, 2017 4:56 PM
  • User1120430333 posted
    Where does it say the EF DB first can't be used with EF core? lMHO, EF Code first is not suited for complicated usage or DB schemas, which only leads to the developer getting burnt.
    Thursday, October 26, 2017 6:02 PM
  • User-821857111 posted

    Where does it say the EF DB first can't be used with EF core?
    EF Core doesn't support EDMX files, so that particular DB First option is not available. It does, however, support generating model classes from an existing database: http://www.learnentityframeworkcore.com/walkthroughs/existing-database

    lMHO, EF Code first is not suited for complicated usage or DB schemas
    Really? Why?

    Friday, October 27, 2017 12:49 PM
  • User-821857111 posted

    So I have to use fluent-api to specify for all entities PK and FK?
    No. You only need to use configuration if your model doesn't follow conventions. When configuring keys, you can use either attributes or fluent API. 

    Friday, October 27, 2017 12:51 PM
  • User1120430333 posted

    DA924

    Where does it say the EF DB first can't be used with EF core?

    EF Core doesn't support EDMX files, so that particular DB First option is not available. It does, however, support generating model classes from an existing database: http://www.learnentityframeworkcore.com/walkthroughs/existing-database

    DA924

    lMHO, EF Code first is not suited for complicated usage or DB schemas

    Really? Why?

    It's because too many inexperienced developers that don't even have the 101 basics on DB administration are now saddled with doing DB administration through EF code first, because that is what is being taught is Code first, they really don't know any better as to what they should be doing with DB administration, and they really don't have a clue on the basics of DB administration let alone working with EF in general EF even at the basic level.

    Heck, they can barely use EF period, let alone the administration of the DB, and this includes those who are professionals too. But that's what they see is the cheesecake teachings of EF and Code first when it comes to Web based solutions concerning ASP.NET and MVC solutions.

    So the final result is they get into trouble with EF Code first,  and one see it time and time again as the fly into the MSDN EF forum seeking help on 'I am using Code first'.

    Myself, I won't touch EF Code first with a 10 foot pole, and I will take DB first over Code first every time. I have models that I have worked with  that are based on 80 tables or more,  and I don't have time for the cheesecake teachings of EF Code first and ASP.NET MVC. I have the common since to know that Separation Of Concerns should be implemented by use of a Repository and DAL with EF being used at the DAL level and not up at the client-side in a controller, the cheesecake.

    So if the EF team thinks that EF code first with EF core is the way to go,  or one has to hit the highway because they are abandoning DB first, then I'll hit the road on EF core and never use it.

    Friday, October 27, 2017 2:14 PM
  • User-821857111 posted

    So if the EF team thinks that EF code first with EF core is the way to go,  or one has to hit the highway because they are abandoning DB first, then I'll hit the road on EF core and never use it.
    They still support a DB first approach, but without the filthy EDMX stuff that used to come with it. Now the reverse engineering tools generate POCO model classes instead. 

    Monday, October 30, 2017 5:07 PM
  • User1120430333 posted

    DA924

    So if the EF team thinks that EF code first with EF core is the way to go,  or one has to hit the highway because they are abandoning DB first, then I'll hit the road on EF core and never use it.

    They still support a DB first approach, but without the filthy EDMX stuff that used to come with it. Now the reverse engineering tools generate POCO model classes instead. 

    I don't think I'll ever use EF core for the simple fact that I don't believe in DB access from any MVC or WebAPI controller. In my case and always, EF will be sitting behind a DAL using the DTO design pattern, which allows me to continue to use EF DB first traditionally using the filthy EDMX. Like I said, I am not into the cheesecake concerning ASP.NET MVC and look at MVC traditionally like I look at MVP using Web or Windows forms in the traditional sense.

    Tuesday, October 31, 2017 1:07 PM
  • User-821857111 posted

    I'm not sure I understand your point. You don't have to have DbContext objects in your controllers when you are using EF Core. You make it sound as though that pattern is somehow forced on you by EF Core?

    Monday, November 6, 2017 4:43 PM
  • User1120430333 posted

    What is EF Core going to buy me in a n-tier solution where EF Core is sitting in a DAL with the DAL sitting behind a WCF Web service? 

    Monday, November 6, 2017 11:49 PM
  • User-821857111 posted

    Huh?

    Tuesday, November 7, 2017 8:47 PM
  • User1120430333 posted

    Huh?

    I am using EF DB first with the EDMX on the backend of  n-tier solutions, which does what I need it to do. What would be the reason even if it is possible, that I would switch to EF core with using EF core in a n-tier solution, which would be used in a n-tier Web based solution using either WCF Web service or Web API to hosting the DAL that was using EF core?

    If there is no advantage in using EF core over traditional EF usage in this scenario, then EF core has no advantage over traditional EF usage.

    Wednesday, November 8, 2017 2:33 PM
  • User-821857111 posted

    There wouldn't be any reason in that scenario. I got the impression from your earlier posting that you were rejecting the idea of ever using EF Core under any circumstances because it does not support "Database First" (although it does, just not the EDMX approach).

    I would only ever swap traditional EF for EF Core if I needed to migrate an application to a non-Windows environment. Otherwise, as you say, there is no point in doing so.

    Thursday, November 9, 2017 10:37 AM