Document Reverse Engineering at the conceptual level

[ajcvickers]

Issue #506 is about how to use the command line tools, but we also need better documentation on why and how to use reverse engineering at the conceptual level.

[bricelam]

I think Rowan's original intentions were to add a new node under EF Core with these sub-nodes:

• Schema management
  • Migrations
  • Reverse engineering

I'll add it as part of #507

[bricelam]

Note to documentor: don't forget to mention Name= and how it pairs well with user secrets,

[cccuscott]

I see this didn't make it into 2.1 release. I am currently transitioning our SaaS product to .netcore (Great work) but we are a heavy DB first/reverse engineer shop for our EF stuff. Is there a quick and dirty on disabling migrations and doing reverse engineering?

[ErikEJ]

Have a look at EF Core Power Tools (I am the author) https://github.com/ErikEJ/EFCorePowerTools/wiki/Reverse-Engineering

[bricelam]

Some ideas:

• Connection strings
  • escaping in PS and command-line
  • from config/user secrets (Name=)
• Provider name is NuGet package/assembly name
• Specifying tables (--schema, --table)
• Preserve database names (--use-database-names)
• Directories and namespaces (--context-dir, --output-dir)
• Context name (--context, defaults to database name)
• What we reverse engineer
  • foreign key columns
  • Bi-directional navigations
  • All constraints (safe to remove some)
  • Sequences
• What we don't reverse engineer
  • Inheritance
  • Table splitting/owned types
  • Concurrency tokens
  • Views/tables without PK--Query types (TODO)
  • Unsupported Column Types
• Data Annotations or Fluent API
• You can change it, but changes are blown away without update from database
• Re-scaffolding (--force)

[bricelam]

(Poaching this from @smitpatel)