locked
Adding EF to Existing Project wiht Existing Database RRS feed

  • Question

  • User1122355199 posted

    Hello everyone and thanks for the help in advance.  I am starting to lean EF and have an existing project with models already designed.  I also have the database completed.  Both were done manually rather than using any wizards, etc.  I want to start using EF with this existing project, but am not sure whether this should be done a Code-First or DB First and whether selecting either of these will conflict with existing code or database.  Also, while I like the idea of using scaffolding to create code, I prefer to know what is going on behind the scenes.  Are there any tutorials for manually setting up EF?

    Friday, July 27, 2018 10:27 AM

Answers

  • User1120430333 posted

    kmcnet

    Thanks for the response.  There were no classes generated inside of the Models folder other than the AccountView, Identity, and Manage View models created when the project is created.  I'm using VS 2015.  Did I miss a step?

    The classes are there in plain sight. Myself when using DB first, I always install the model into a Model folder, like the DAL.Model folder so that I can clearly see everything belonging to a model for a given context with contexts for different databases, likle DAL.Model.Payroll, GeneralLedger, etc., and etc being in the project. 

    Using VS Project's  "Add New Folder",  create a Model folder,  then select the folder and "Add New Item", select a Model folder that you made, which is namespace seperation , and install EF with the EF wizard into the Model folder. It's how I always create an EF Model for any given database context used by EF. Even with using Code first, I would still be using project folder namespace seperation and not have all contexts in the root project but rather in sperate folders.

    //------------------------------------------------------------------------------
    // <auto-generated>
    //     This code was generated from a template.
    //
    //     Manual changes to this file may cause unexpected behavior in your application.
    //     Manual changes to this file will be overwritten if the code is regenerated.
    // </auto-generated>
    //------------------------------------------------------------------------------
    
    namespace DAL.Model
    {
        using System;
        using System.Collections.Generic;
        
        public partial class Enrollment
        {
            public int EnrollmentID { get; set; }
            public Nullable<decimal> Grade { get; set; }
            public int CourseID { get; set; }
            public int StudentID { get; set; }
        
            public virtual Course Course { get; set; }
            public virtual Student Student { get; set; }
        }
    }
    

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, July 28, 2018 7:36 PM
  • User475983607 posted

    kmcnet

    but I see the classes are created in some type of .tt file and not directly into the models folder.  Is this how it should work or am I doing something wrong?

    Yes, and the default behavior of DB first.  The tt file is a T4 template which is basically a code generator that executes on save.  Visual Studio displays the class as child node of the tt file.  

    I prefer, as stated above, Code First.  I like the idea of pushing updates to the DB rather than writing SQL scripts and refreshing the models.  With Code First all the code is in your Visual Studio project and under source control, if you are using source control.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, July 29, 2018 3:25 PM
  • User1724605321 posted

    Hi kmcenet,

    While using Code First Approach , you will use  Code First Migrations here for database changes. This will allow you to better manage the changes you make to the database. In addition , some concerns about how to migrate production database with Entity Framework Code First here is for your reference .

    Best Regards,

    Nan Yu

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 30, 2018 2:50 AM
  • User753101303 posted

    Hi,

    No you can tell up to which "migration" you want to update your db. Which doc are you using? See options for update-database.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 30, 2018 11:47 AM

All replies

  • User475983607 posted

    Are there any tutorials for manually setting up EF?

    Yeah, the Getting Started Tutorial on this site cover the basics.

    https://www.asp.net/mvc/overview/models-data

    I want to start using EF with this existing project, but am not sure whether this should be done a Code-First or DB First and whether selecting either of these will conflict with existing code or database.

    I prefer code first.  I recommend taking time to learn the technology then you should be able to make a decision. 

    Friday, July 27, 2018 10:41 AM
  • User1122355199 posted

    Thanks for the response.  I've been looking around on that site prior to posting, but the examples seem to only deal with fresh projects, rather than existing ones.  I did try a DB first trial in a new project and see all of the classes are generated in the EDMX rather than classes within the Models folder.  Is that one of the reasons you suggest Code First?  As you already know, I'm refactoring a lot of code and this threw me for another loop.

    Friday, July 27, 2018 7:06 PM
  • User475983607 posted

    kmcnet

    I've been looking around on that site prior to posting, but the examples seem to only deal with fresh projects, rather than existing ones

    Scaffold an existing DB using Code First.

    https://msdn.microsoft.com/en-us/library/jj200620(v=vs.113).aspx

    kmcnet

    I did try a DB first trial in a new project and see all of the classes are generated in the EDMX rather than classes within the Models folder.  Is that one of the reasons you suggest Code First?

    I used EDMX for years as that's all there was.  I moved to EF and ASP Core which only has Code First.  After working with Code First I prefer it to DB First.  Working in a team environment with source control was a little challenging dealing with migrations though.

    It took me a few week to become comfortable with Code First.  I built proof of concepts that mirrored tasks regular development.  Then I practiced adding/removing migrations, crafting custom migrations, seeding data, deployments, working with source control, etc. 

    I already had EDMX experience so I did not have to learn EDMX too.

    Anyway, that's how I learn stuff.  Read the docs and practice.

    Friday, July 27, 2018 7:45 PM
  • User1120430333 posted

     I did try a DB first trial in a new project and see all of the classes are generated in the EDMX rather than classes within the Models folder.

    The classes are there in the Model folder. You have to know where to look for them. The classes are generated from the edmxThe EF graphical model designer also works with the edmx

    Myself, I choose DB first, becuase it's easier to work with from what I have seen. I'll choose EF Core DB first, which doesn't use edmx  as it seems a lot more easier to use than Code first with all of its migration logic that never seems to work where one has to step-in and correct things every time.

     I have used Code first in Core and none  Core too through a couple of tutorials and just getting Code first stuff to work through the tutorials are even a pain.  You see the problem to me with Code first is not programming against the database in code and the same holds true for DB first too with using Linq and all of that stuff. The problems start with the deployment and migration with  Code first, and it's a lot pain and frustration.. 

    Saturday, July 28, 2018 6:22 PM
  • User1122355199 posted

    Thanks for the response.  There were no classes generated inside of the Models folder other than the AccountView, Identity, and Manage View models created when the project is created.  I'm using VS 2015.  Did I miss a step?

    Saturday, July 28, 2018 6:52 PM
  • User1120430333 posted

    kmcnet

    Thanks for the response.  There were no classes generated inside of the Models folder other than the AccountView, Identity, and Manage View models created when the project is created.  I'm using VS 2015.  Did I miss a step?

    The classes are there in plain sight. Myself when using DB first, I always install the model into a Model folder, like the DAL.Model folder so that I can clearly see everything belonging to a model for a given context with contexts for different databases, likle DAL.Model.Payroll, GeneralLedger, etc., and etc being in the project. 

    Using VS Project's  "Add New Folder",  create a Model folder,  then select the folder and "Add New Item", select a Model folder that you made, which is namespace seperation , and install EF with the EF wizard into the Model folder. It's how I always create an EF Model for any given database context used by EF. Even with using Code first, I would still be using project folder namespace seperation and not have all contexts in the root project but rather in sperate folders.

    //------------------------------------------------------------------------------
    // <auto-generated>
    //     This code was generated from a template.
    //
    //     Manual changes to this file may cause unexpected behavior in your application.
    //     Manual changes to this file will be overwritten if the code is regenerated.
    // </auto-generated>
    //------------------------------------------------------------------------------
    
    namespace DAL.Model
    {
        using System;
        using System.Collections.Generic;
        
        public partial class Enrollment
        {
            public int EnrollmentID { get; set; }
            public Nullable<decimal> Grade { get; set; }
            public int CourseID { get; set; }
            public int StudentID { get; set; }
        
            public virtual Course Course { get; set; }
            public virtual Student Student { get; set; }
        }
    }
    

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, July 28, 2018 7:36 PM
  • User1122355199 posted

    Thanks for the response.  I'm not really sure:

    The classes are there in plain sight.

    After following your steps, I did get the code to be generated into the Models folder, but I see the classes are created in some type of .tt file and not directly into the models folder.  Is this how it should work or am I doing something wrong?

    Sunday, July 29, 2018 3:01 PM
  • User475983607 posted

    kmcnet

    but I see the classes are created in some type of .tt file and not directly into the models folder.  Is this how it should work or am I doing something wrong?

    Yes, and the default behavior of DB first.  The tt file is a T4 template which is basically a code generator that executes on save.  Visual Studio displays the class as child node of the tt file.  

    I prefer, as stated above, Code First.  I like the idea of pushing updates to the DB rather than writing SQL scripts and refreshing the models.  With Code First all the code is in your Visual Studio project and under source control, if you are using source control.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, July 29, 2018 3:25 PM
  • User1122355199 posted

    Thanks.  That makes sense and it appears to be cleaner.  One last question:

    I like the idea of pushing updates to the DB rather than writing SQL scripts and refreshing the models

    Because I'm just learning, I'm a little concerned about pushing updates to a DB, especially a production DB.  I'm still reading through the documentation and see you can suppress the updates, but I'm not sure how to push only one update.  Or does it push all updates?

    Sunday, July 29, 2018 7:41 PM
  • User1724605321 posted

    Hi kmcenet,

    While using Code First Approach , you will use  Code First Migrations here for database changes. This will allow you to better manage the changes you make to the database. In addition , some concerns about how to migrate production database with Entity Framework Code First here is for your reference .

    Best Regards,

    Nan Yu

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 30, 2018 2:50 AM
  • User475983607 posted

    I'm a little concerned about pushing updates to a DB, especially a production DB.  I'm still reading through the documentation and see you can suppress the updates, but I'm not sure how to push only one update.  Or does it push all updates?

    This is not a Code First question.  This is a procedure question related to software development.  Most dev shops use source control to branch features. Only the expected code is deployed to production.

    To answer your question, yes, you can suppress migrations and manually run a SQL deployment script.  I do not recommend purposefully placing the code base in a different state than the database regardless of implementing DB First, Code First, or ADO.NET.

    Monday, July 30, 2018 11:34 AM
  • User753101303 posted

    Hi,

    No you can tell up to which "migration" you want to update your db. Which doc are you using? See options for update-database.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 30, 2018 11:47 AM
  • User1120430333 posted

    Thanks for the response.  I'm not really sure:

    DA924

    The classes are there in plain sight.

    After following your steps, I did get the code to be generated into the Models folder, but I see the classes are created in some type of .tt file and not directly into the models folder.  Is this how it should work or am I doing something wrong?

    Really,  what's the concern here? For the migration point, myself, I would be using VS's MS SQL Server Project to do the migration of the database, which I have used in the past. Each developer had MS SQL Server Express installed on their machine. The developer could through TFS get the latest DB schema and apply it to the SQL Express database where they could make changes to schemas or whatever, verify what was done, run code against the database  and check the project back into TFS for auto integration and deployment, along with the application/program source code that matched the database with the whole shooting match ready for auto integration and deployment.   

    It's not the job of an ORM to do it. An ORM is not a database tool. EF, an ORM,  has gone too far IMO with the migration nonsense that doesn't work,  or if it does work,  and one wants to do something else other than what the migration is doing, then one is blocked and has to eliminate the blockage or find a way to work around it.  

     https://visualstudio.microsoft.com/vs/features/ssdt/

    Monday, July 30, 2018 6:40 PM
  • User475983607 posted

    It's not the job of an ORM to do it. An ORM is not a database tool. EF, an ORM,  has gone too far IMO with the migration nonsense that doesn't work, 

    Migrations do indeed work and are invoked through a separate command line tool. 

    or if it does work,  and one wants to do something else other than what the migration is doing, then one is blocked and has to eliminate the blockage or find a way to work around it.

    A migration is just code that submits a batch which is no different than using SSMS.  One very powerful pattern in migrations is the concept of up and down.  Basically, the control to undo a migration.

    Monday, July 30, 2018 7:05 PM
  • User1120430333 posted

    DA924

    It's not the job of an ORM to do it. An ORM is not a database tool. EF, an ORM,  has gone too far IMO with the migration nonsense that doesn't work, 

    Migrations do indeed work and are invoked through a separate command line tool. 

    DA924

    or if it does work,  and one wants to do something else other than what the migration is doing, then one is blocked and has to eliminate the blockage or find a way to work around it.

    A migration is just code that submits a batch which is no different than using SSMS.  One very powerful pattern in migrations is the concept of up and down.  Basically, the control to undo a migration.

    I don't like it, and I cringe every time I encounter it.

    Monday, July 30, 2018 7:33 PM
  • User753101303 posted

    I must say I'm not a big fan as well (not even code first). The problem is that it seems to turn the db into a black box for new developpers and weaken their db design skill.

    That said you can still generate update scripts etc... (and it seems they are moving away from runtime changes to favor that). As all tools it needs to be used wisely and knowing what happens under the hood can help.

    Tuesday, July 31, 2018 8:58 AM