C# 将自定义.NET ORM迁移到实体框架/Dapper

我继承了一个规模庞大、有点迷宫式的项目。流量足够大，需要优化数据访问，因此我开始将javascript调用的一些WCF服务转换为Web API

不幸的是，数据库的主键（不是自动递增的）也由自定义ORM通过查询返回下一组要使用的ID的MySQL函数来管理。然后ORM缓存它们并将它们提供给应用程序。数据库本身是一个不断增长的2 TB数据，这将使停机时间变得非常重要

我曾计划使用Dapper，因为我在过去享受过易用性/性能，但从这个定制ORM中剔除这个数据库似乎令人望而生畏，而且容易出错

问题:

• 有人对处理大型项目有什么建议吗
• 我应该更多地关注将数据库迁移到一个全新的数据结构中吗？（它也需要显著的标准化！）

---

我的浅见：
处理遗留代码时的一条经验法则是：如果某个代码有效，请保持这种方式。如有必要，进行更改或改进。主要原因是:
• 当您想要为系统添加业务价值时，重新设计的效果几乎为零
• 这个系统，无论好坏，都能正常工作。不管你多么小心，你总是可以用结构性的改变来搞乱一些事情
此外，这在很大程度上取决于公司的计划以及更改的原因（添加功能、修复bug、改进设计或优化资源使用）。我的经验告诉我，时间和预算非常重要，尽管我们总是想重新设计（或者在某些情况下，从头开始编写代码），但最重要的是业务目标和附加值
在您的情况下，可能没有必要更改所有ORM。如果您说ID是缓存的，那么更好的方法是修改PK，在PK上添加identity属性（每个表上都有正确的起始值）。之后，您可以删除获得下一个Id的代码的特定部分
在某些情况下，非规范化数据库有其原因。我见过这样的情况：数据被复制到表中以避免连接，这会影响性能。我说的是数百万张唱片
更改ORM的原因：可能是因为它效率低下，或者没有关闭非托管代码（在这种情况下，更好的方法是实现IDisposable接口）。如果它有效，也许更好的方法是在需要创建新功能时使用新的ORM。如果项目需要进行重构以达到优化目的，则需要将更改应用于瓶颈，而不是整个代码
关于这个话题有很多讨论。一个很好的推荐资源是Michael Feathers的“有效地使用遗留代码”，或者Eric Evans的“在遗留系统的包围下开始使用DDD”

---

你好
很好的视角。我更多的是从“全部重建”的角度来看应用程序，但增加业务价值是一个重要的、现实的观点。也许，增量升级定制ORM并为其提供更好的接口（例如Web API）是最好的方法。谢谢你的回答和资源！