如果使用面向功能的编程，“阻抗不匹配”会消失吗？

Question

我目前看到很多关于代码中的实体建模的工作以及对函数式编程的兴趣。在面向对象系统工作了几年之后，我一次又一次地遇到“阻抗不匹配”问题。

由于 Transact SQL 实现了一些 FOP，数据集以声明方式描述为 Set，“阻抗不匹配”是否会消失。如果是这种情况，我试图确定，是否需要以代码形式开发领域模型，或者是否可以使用 SQL 和关系理论的旧技术和尝试过的技术。

我知道目前正在大力推动编写实体层和 ORMS 以尝试减轻这种阻抗不匹配并使系统作为对象工作。

这项工作是否反映出手头可能存在更大的问题，并且“阻抗不匹配”对于面向对象的设计/编程来说更加令人担忧，因为在处理 RDBMS 交互时，整个范例可能不是最佳解决方案.

我正在考虑从 c# 迁移到 f# 的影响，全职并适用于所有代码库。我认为我的思维方式转变可能有问题。

Answer 1

否

这是简短的答案。然而，功能编程“模式”将减少阻抗失配。但只有在花费大量时间学习功能样式后才能期待这一点。也期望您的 OO 样式阻抗不匹配会随着同样获得的智慧而改善。

函数式编程教您如何解决数据和函数之间的关系，就像解决 soduko 难题一样。功能样式为您提供了了解为什么会发生许多阻抗不匹配的关键知识。然而，即使有了这些知识，阻抗仍然会发生。它们发生是因为编程是将树和图映射到列表和树中。它是关于将“高级”构造（在数据和功能“空间”中）映射到“低级”映射。每个映射都可能运行良好，直到出现新需求并引起麻烦，然后需要重新访问映射。这就是生活。

仍然只有函数式编程足够“纯粹”，可以清晰地理解这些不匹配是如何发生的以及为什么会发生。因此，如果您想掌握软件架构，就应该投入尽可能多的时间和精力来学习函数式编程。

Answer 2

如果您不将关系数据映射到对象（不要使用 ORM），那么阻抗不匹配就会消失，那么您的编程风格就没有那么重要了。