search

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
706 stars 229 forks source link

Optimizing through hash values #409

Open feldrim opened 6 years ago

feldrim commented 6 years ago

We have used EF POCO Generator for a legacy enterprise application with about 3400+ tables and 800+ views. It was database-first using EDMX files. But we were not going to use all of them, it was a shared database for different services. Name or scheme based filtering wasn't enough.

So we used XML file to list all the tables which we produced from EDMX by replacing unused data using Regex, then manually delete the table names we would not use. We then had an XML object consisting of name and hash properties. Hash values are created with customized T4 template by checking the columns, data types, keys et cetera and making an MD5 hash of them. So next time it will check hash values then try to create the POCO if needed.

It's CPU heavy but it requires less RAM since it creates only the changed entities. Writing files and adding them to project requires more time than all the computing. Overall it was helpful but needs more optimization. So:

  1. Using XML catalog of tables alternative to filtering
  2. Checking changes first before creating files
  3. Optimizing the calculation process

would be a good enhancement.

sjh37 commented 6 years ago

Wow, that is a lot of tables. I quite like the idea of using hashes to save on writing time.

feldrim commented 6 years ago

It was a pain, a severe pain. Yet thanks to EF POCO Generator, we could manage to make the spaghetti code a little less spaghetti, a lot more manageable. First a shared class library of entities then a Nuget package of them, made the whole ecosystem of systems more manageable. We have customized a lot though and the mappings of bad database design where a foreign key is related to many other foreign keys etc literally ruined us. I can't remember all of them but this hash idea was my solution to one of the problems. If I can remember other customizations, I'll open issues about them too. Maybe it might help enhance the application.

zbalkan commented 4 years ago

Do we have this in the latest version?

sjh37 commented 4 years ago

Hi @zbalkan No this case is still open and nothing has been implemented with regard to this case. I do not recommend have a single large database context. It works, but is painfully slow. I recommend installing the generator into every service where you need to access the database. Then use filters to filter down the db context to just the tables you need for the service to function. That way the service can spin up a db context in milliseconds, instead of minutes.

I'm keeping this case open to add a hash value for the columns, data types, keys etc. I'll create an enum for the hash type, MD5, SHA256 etc so users can choose their own.