Enhancement : Reverse Engineer from an EDMX file?

[omatrot]

I'm wondering if we could in the future reverse engineer from an existing edmx file ?
Would it be difficult to port the code that existed in the initial EF Power tools ?
I may have some time to dedicate to this task in the near future.

[ErikEJ]

I think it could be quite difficult, as the current reverse engineering is based on a database model, not a conceptual edmx model... But interesting thought.

Your task would be to create a class that can create a DatabaseModel from an edmx, have a look at the code that does this from a .dacpac. (that has been serialized into a TSqlModel)

[ErikEJ]

Maybe you could use this? https://archive.codeplex.com/?p=linqtoedmx

[omatrot]

All right, let me see what I can do.

[ErikEJ]

Perfect, ping me with any design questions.

[ErikEJ]

Found this - LINQ to EDMX looks vry old: https://github.com/robertmclaws/EDMXParsingSample/blob/master/src/EdmxParsingSample.Data/EdmxLoader.cs

[omatrot]

@ErikEJ Just to let you know that I've started the porting process of the old LinqToEdmx to .NET Standard 2.1.

[ErikEJ]

Wauw!

[omatrot]

I've published the Linq2Edmx and Linq2xsd nuget packages.
Do you want me to create a branch corresponding to the issue in my forked repo to start the integration process?

[ErikEJ]

If you think it adds value, sure, it will mainly be an implementation of DatabaseModelFactory.

i suggest you start with the code generation parts, and verify by running the console app.

[omatrot]

I also have to say that I'm using Visual Studio 2019 for Mac. The EFCorePowerTools project is unrecognised in this environment. I'm open to some alternative build/debug guidelines. Thanks in advance.

[ErikEJ]

This is a Visual Studio project, but you could maybe run the code generation parts on Mac...

The end result could be a package similar to the Nuget package for .dacpac support.

But being able to open the solution file is most likely a must, are you able to do that?

If not, we could take a Teams call and I can walk you through the moving parts?

[omatrot]

The solution file opens fine. VS complains that this project is an unknown solution item type.

[ErikEJ]

Yes, that is expected for the Vsix project, but you should be able to open the .net Core projects, and they are the important ones...

We are talking in the blind here, is my impression

[omatrot]

All the other projects are loading correctly ;)

[ErikEJ]

Ok, then you are good to proceed!

[omatrot]

Yep !

Correct me if I'm wrong but I think I should create two new projects:

• ErikEJ.EntityFrameworkCore.5.Edmx
• ErikEJ.EntityFrameworkCore.Edmx

To follow what has been done for Dacpac?

I'll let you validate the namespaces and project names though.

[ErikEJ]

Yes, that would be the final outcome.

[ErikEJ]

Hmmm... What provider will this target?

The DatabaseModel is provider specific?

[omatrot]

No, it will be provider agnostic.

[ErikEJ]

Curious how that will pan out in real life... And runtime it will execute against some database, I presume??

[omatrot]

I think it will depend on what is missing in the Edmx file.

For instance, Index informations are not there, but we may optionally connect to the database to get them. Primary and foreign keys are there of course.

For me the main idea is to never create the database from the scaffolding data, just be able to work with a generated context of an existing database from which one had generated (and tweaked) an edmx in the past.

[ErikEJ]

Thanks for the explanation! Makes sense to me...

[omatrot]

Hi @ErikEJ
Quick question just to clarify something: Microsoft.EntityFrameworkCore.Scaffolding.Metadata.DatabaseModel is about the storage part of the relational database? Is there an equivalent for the conceptual part? The EDMX contains both and the mapping between the two.

[ErikEJ]

@omatrot I assume it could be this one: https://github.com/dotnet/efcore/blob/main/src/EFCore.Relational/Metadata/IRelationalModel.cs

[omatrot]

I would provide both then, if that makes sense to the tooling. That makes sense to me anyway.

[ErikEJ]

Tooling does not use the IRelationalModel, but feel free to expose it, we should consider publishing a NuGet package.

[omatrot]

I'm not done yet ;)
If I understand correctly, the tooling expose an IDatatabaseModel that is later processed by EF scaffolding to produce the entities, their configurations and the context?
The EDMX file already contains all that is needed to produce the entities, their configurations and the context.

[ErikEJ]

Correct, look at the .dacpac Databasefactory

[omatrot]

Hi @ErikEJ
I think I'm ready to prepare a pull request for this.
Stay tuned.
Thanks for your patience.

[ErikEJ]

Wauw - exciting!

[omatrot]

I may have spoken too fast...
I'm confused about what I've done around the IRelationalModel Interface. There seems to be no factory available to create instances of this interface. Could you double check to confirm? And may be provide an alternative?
Thanks in advance.

[ErikEJ]

I sincerely doubt there will be many consumers of the IRelationalModel - but do a PR so we can have a fact based discussion?

[omatrot]

PR opened.

[ErikEJ]

The PR is now merged, and you can test it by picking an EDMX file via the Select Data Source dialog.

Thanks for your patience!

[ErikEJ]

Could you describe this selling point of this feature in a sentence? I plan to tweet that it is now available in the latest daily build.

[omatrot]

I’ll do that. I may be wrong but I suspect that you now allow to select an edmx, then process as usual to select what to reverse engineer ? The edmx file already contains that information in the so called conceptual model. We could bypass this step, if I provide you what you need.

[ErikEJ]

Why don't you try it out?

[omatrot]

I've tried it out ;)
As I was saying, the 'Choose Database Object' step could be avoided completely or displayed as readonly because I can provide you with what the .edmx file contains in the conceptual model, which may specify excluded columns and custom renaming, and is not used so far.

Selling point:
Now you can leverage your existing/maintained .edmx files to scaffold EF Core entities and context.