Entityframework.docs: 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)