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

Question

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

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

我知道目前在编写实体层和ORMS方面有一个很大的推动，试图缓解这种阻抗不匹配，并让系统像对象一样工作。

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

我正在考虑从c#转移到f#的影响，全职和所有代码库。我想我可能在改变我的思维定势方面有问题。

Answer 1

没有

这是一个简短的答案。然而，函数式编程“模式”将减少阻抗失配。但只有在花了很长时间学习函数式风格之后才会想到这一点。同样希望你的OO风格阻抗不匹配也能通过同样的智慧得到改善。

函数式编程教您如何计算数据和函数之间的关系，就像您解决soduko难题一样。函数式风格为您提供了关键知识，帮助您了解为什么会发生许多阻抗不匹配的情况。然而，即使有了这些知识，障碍仍然会发生。它们之所以会发生，是因为编程就是将树和图映射成列表和树。它是关于将“高级”结构(在数据和函数“空间”中)映射到“低级”映射。每个映射都可以很好地工作，直到有新的需求出现并导致问题，然后需要重新访问映射。这就是生活。

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

Answer 2

如果不将关系数据映射到对象(不使用ORM)，那么不匹配问题才会消失，编程风格也就无关紧要了。