我继承了一个规模庞大，有点迷宫的项目。流量足以想要优化数据访问，因此我开始将一些由javascript调用的WCF服务转换为Web API。
不幸的是，数据库的主键（不是自动递增）也是由定制ORM通过查询返回下一组要使用的ID的MySQL函数来管理的。 ORM然后缓存它们并将它们提供给应用程序。数据库本身是一个不断增长的2 TB数据，这将使停机时间变得非常重要。
我曾经计划使用Dapper，因为我过去喜欢轻松/性能，但是从这个自定义ORM中删除这个数据库似乎令人生畏并容易出错。
问题：
答案 0 :(得分：2)
我的拙见：
处理遗留代码时的经验法则是：如果有效的话，请保持这种方式。如有必要，请进行更改或改进。主要原因是：
此外，它在很大程度上取决于公司的计划改变的原因（添加功能，修复错误，改进设计或优化资源使用）。我谦虚的经历告诉我，时间和预算非常重要，虽然我们总是想重新设计（或者在某些情况下，从头开始编写代码），但最重要的是业务目标和附加值。
在您的情况下，也许没有必要更改所有ORM。如果你说ID被缓存了，一个更好的方法是修改PK，添加身份属性（每个表上有正确的起始值）。之后，您可以删除获得下一个Id的代码的特定部分。
在某些情况下，非标准化数据库有他的理由。我见过将数据复制到表中以避免连接的情况，这会影响性能。我说的是数以百万计的记录......
更改ORM的原因：可能是因为它效率低下，或者它没有关闭非托管代码（在这种情况下，更好的方法是实现IDisposable接口）。如果它有效，也许更好的方法是在需要创建新功能后使用新的ORM。如果项目需要重构以进行优化，则需要在瓶颈中应用更改，而不是整个代码。
关于这个话题有很多讨论。一个很好的推荐资源是Michael Feathers的“有效使用遗留代码”，或Eric Evans的“遗留系统包围DDD入门”。
问候！