sjh37 / EntityFramework-Reverse-POCO-Code-First-Generator

EntityFramework Reverse POCO Code First Generator - Beautifully generated code that is fully customisable. This generator creates code as if you reverse engineered a database and lovingly created the code by hand. It is free to academics (you need a .edu or a .ac email address), not free for commercial use. Obtain your licence from
https://www.reversepoco.co.uk/
Other
700 stars 230 forks source link

Import preexisting Models/POCOs/Entities into a new DBcontext #771

Closed fasteddys closed 1 year ago

fasteddys commented 1 year ago

Tool: VS 2022

Hello, I would like understand if this tool can help us.

If we already have the models (no db), where we have a few legacy projects, where I am trying your tool to upgrade into EF. In the previous version, they used Models/Entities ,ADOwith SP's/StoreProcs.

As I upgrade inside the modelnamespace, since we have all/list all the preexisting code/objects/entities/models without a DB context, can you add some help on how to import those source/entities to the reverse POCO is it already there, is it done by these methods? I apologize I was reading the help and could not figure it out, I think its not natively there, but if you can point me to some ideas I can try and do a PR

sjh37 commented 1 year ago

Hi @fasteddys

To import additional models/entities into a reverse poco generated db context, in your <database>.tt file, set

Settings.DbContextClassModifiers     = "public partial";
Settings.DbContextInterfaceModifiers = "public partial";

This will generate a db context like:

// Generated db context
public partial class MyDbContext : DbContext, IMyDbContext
{
    public MyDbContext()
    {
        InitializePartial();
    }

    public MyDbContext(DbContextOptions<MyDbContext> options)
        : base(options)
    {
        InitializePartial();
    }

This will allow you to add more functionality to your MyDbContext class and your interface class IMyDbContext in a separate file that is not generated:

public partial interface IMyDbContext
{
    DbSet<MyManuallyCreatedEntity> MyEntities { get; set; }
}

public partial class MyDbContext
{
    public DbSet<MyManuallyCreatedEntity> MyEntities { get; set; }

    partial void InitializePartial()
    {
        // Any initialisation during constructor can be done here
    }

    partial void OnModelCreatingPartial(ModelBuilder modelBuilder)
    {
        modelBuilder.ApplyConfiguration(new MyManuallyCreatedEntityConfiguration());
    }

    partial void DisposePartial(bool disposing)
    {
        // optional
    }
}
fasteddys commented 1 year ago

I was trying to import existing models, but after following your instructions I failed, where or how do I tell it to import models from a different namespace.

My goals is create one new consolidated/clean POCO models class lib. for all the models (diff students are creating their own models), i.e. consolidate a few fragmented libs. and some other databases into one main model.

sjh37 commented 1 year ago

Easier if I create a demo application so you can see how its done. Some entities are generated and some are manually created. All entities end up in the same database context, allowing for Reverse POCO to still overwrite its database context without losing any changes in your partial database context which extends it with your own entities.

MixOfReversePocoAndManualEntities.zip

I have updated the partial wiki article with the above example application.

fasteddys commented 1 year ago

Thanks @sjh37 will try it.

We are looking for one good solution to manage the import of various poco's, Databases, context to one centralized model.. sorry about the cross ask in various places, just trying to find or shepherd one a tool.


To add some details to my nebulous question, many entities and models are created in different namespaces, due to various developers naming choices for whatever reason.

I want to show them, using your tooling, they can import those into your tools purview and manage is via your tool. So, in a sense I want to see if I can consolidate all those fragmented classes/poco under your tool and later manage everything from your tool going forward.

One suggestion, are you planning GUI at some point... if had tabbed sections, which guided the developers on which ones to use it would gain a lot of traction.

Also, it would be nice if you could support plugins or some extension mechanism to not just scaffold the context, but also, DTO's and controllers, a plain shell to begin and people can modify and push a PR, it would evolve and mature over time. Dont mind me... just a suggestion. thanks

sjh37 commented 1 year ago

@fasteddys No problem. I like the idea of auto-generating DTO's and the mapping mechanism between entities and those DTO's. However, controllers would not make sense to generate as I would not know what to put in them by default.