c# - 将自定义 .NET ORM 迁移到 Entity Frame/Dapper

Question

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

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

我曾计划使用 Dapper，因为我过去很喜欢它的易用性/性能，但是让这个数据库脱离这个自定义 ORM 似乎令人畏惧并且容易出错。

问题:

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

Answer 1

我的拙见:

处理遗留代码时的经验法则是:如果有东西有效，就保持这种状态。如有必要，进行更改或改进。主要原因有:

• 当您想要为系统增加业务值(value)时，重新设计的效果几乎为零。
• 无论好坏，这个系统都有效。无论您的护理如何，您总是可能因结构变化而弄乱一些东西。

此外，这在很大程度上取决于公司的计划和更改的原因(添加功能、修复错误、改进设计或优化资源使用)。我的卑微​​经验告诉我，时间和预算非常重要，尽管我们总是想重新设计(或者在某些情况下，从头开始编码)，但最重要的是业务目标和附加值。

就您而言，也许没有必要更改所有 ORM。如果您说 ID 已缓存，更好的方法是修改 PK，在其上添加身份属性(在每个表上使用正确的起始值)。之后，您可以删除获取下一个 ID 的代码的特定部分。

在某些情况下，非规范化的数据库有他的原因。我见过将数据复制到表以避免连接的情况，这会影响性能。我说的是数百万条记录...

更改 ORM 的原因:可能是效率低下，或者没有关闭非托管代码(在这种情况下，更好的方法是实现 IDisposable 接口(interface))。如果可行的话，也许更好的方法是在需要创建新功能时使用新的 ORM。如果项目需要出于优化目的进行重构，则需要将更改应用于瓶颈，而不是整个代码。

关于这个话题有很多讨论。推荐的一个很好的资源是 Michael Feathers 的“有效处理遗留代码”，或者 Eric Evans 的“在遗留系统包围时开始使用 DDD”。

您好!