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

Question

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

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

我知道目前正在努力编写实体层和ORMS来尝试缓解阻抗不匹配并使系统作为对象工作。

这是否能够反映出可能存在更大问题，而“阻抗不匹配”更多地涉及面向对象设计/编程，因为在处理RDBMS交互时，整个范例可能不是最佳解决方案

我正在考虑从c＃转到f＃，全职和所有代码库的含义。我认为我的思维方式可能会有问题。

Answer 1

否

这是简短的回答。然而，功能编程“模式”将减少阻抗不匹配。但是只有在花了很多时间学习功能风格之后才能期待这个。期待你的OO风格阻抗不匹配，以获得相同的智慧。

函数式编程教你如何计算数据和函数之间的关系，就像解决soduko难题一样。功能风格为您提供了解为何发生许多阻抗不匹配的关键知识。然而即使有了这些知识，阻抗仍然会发生。它们的发生是因为编程是将树和图形映射到列表和树中。它是关于将“更高级别”结构（在数据和功能“空间”中）映射到“更低级别”映射。每个映射都可以正常工作，直到新的需求进入并导致麻烦，然后需要重新访问映射。这就是生活。

仍然只有功能性编程足够“纯粹”，以便清楚地了解这些不匹配的发生方式和原因。因此，如果您想掌握软件架构，您应该投入尽可能多的时间和精力来学习函数式编程。

Answer 2

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