从数据库工程看支架EF核心

Question

如何从Visual数据库项目直接构建EF？

优先考虑下列解决办法：

scaffold-dbcontext -connection "provider=ssdtproject, name=myprojectname.sqlproj"
scaffold-dbcontext -ddl "ssdtprojectoutput.sql"
scaffold-dbcontext -ssdtschema "ssdtproject.dacpac"
maintained-third-party-tool myprojectname.sqlproj -EfModelGenerationParameters

这就是整个问题。下面是我的详细情况，以便您能够提供其他解决方案：

尽管微软承认NETCore还没有准备好生产，但从EF 6进程停止到现在也已经有3-4年了，NETCore是唯一的LINQ代码--类似于NETCore兼容性的前进之路。因此开始了一个名为“所以你将使用EF核心”的传奇故事。

这部分是自以为是的，但对我来说(基于25+多年的企业软件设计和开发经验)代码--首先是绝对不可能的。对于一周小的应用程序来说，这是没问题的，但是没有一个合理的模式/过程/实践可以集成约束、视图等。如果没有设计好的视图，实际的业务应用程序最终会在LINQ表达式中出现devs重复的逻辑基础，将代码中的静态字段乱丢以支持LinqKit查询，使用LinqKit等混淆微观组合模式。没有约束，我们最终会有十倍的防御代码要求来处理运行时错误、快速发展的单元和集成测试，以及演示失败成为常态。我们的面向对象的专家要么需要成为SQL专家，要么相反，我们大大增加了寻找和适当补偿工程师的难度。四年前，我在与罗文·米勒( Rowan )的一次详细谈话中指出了所有这些问题(米勒最近离开了EF团队，这对短期解决方案并不是个好兆头)。

模型优先(在以前的EF版本中的视觉.edmx设计器)显然不在桌面上，因为MS解决方案是声明代码--首先是模型优先，然后洗手。因此，一个真正中立的，让我们称之为“合同-第一”的明确性，方法不存在EF核心。

所以，这种咆哮(抱歉，沮丧)让我首先谈到数据库，然后是Scaffold-DbContext。我们的DB架构目前是一个修订控制的数据库项目。除了这方面的一些已知问题之外，还必须使用我们的DB模式(目前是我们的单一事实)，从它重建一个活动数据库，然后从活动数据库返回生成代码，这一切都是我们构建过程的一部分，只是为了验证数据库类型对齐性。相反，我希望能够直接从数据库项目中检测更改并重新生成我的DbContext和相关实体。

SSDT数据库项目似乎使类似数据库的对象在许多通常需要数据库连接的UI中可用。这使我认为，使用数据库模式作为现有工具的源可能是一段很短的路程。例如，在连接字符串中使用元数据提供程序，对EF核心代码进行简单修改，等等。

SQL Sharpener“在设计时使用SQL文件作为真理的来源(例如在SSDT项目中找到的文件)生成，对于早期版本的EF来说，推荐是解决这个问题的解决方案，但它不支持EF。

SQLite和Server紧凑型工具箱刚刚增加了对直接从.DACPAC生成EF模型的支持，但它似乎依赖于EntityFramework反向POCO码第一发生器的这种功能，后者在其TODO列表上突出列出了“支持EF”。此项目的主要贡献者确认不兼容。

帮助?

Answer 1

我一直在挣扎，直到我遇到了卓越的扩展Visual。它的逆向工程工具听起来就像你所需要的。

https://marketplace.visualstudio.com/items?itemName=ErikEJ.EFCorePowerTools