最近，我听到很多关于F＃等函数式编程语言的好东西。另外[和无关]，我也注意到MVC开始大量曝光 - 也许是自Silverlight / WPF推出以来。
如果没有先做我的研究，我从来就不是一个跳槽的人 - 实际上我花了一些时间才能实现.NET的飞跃。有人刚刚在我之前提出的关于早期采用新技术的问题中发表了评论，这让我停下来思考。
我一直在努力争取时间学习WPF，但我现在开始怀疑这是否可行。像F＃这样的语言和MVC编程模型是留下还是仅仅是下一个时尚？或者人们真的认为这些成为C＃/ VB和OOP的潜在替代品？
我的大多数开发都是内部应用程序，可以是在内部网上部署的富Web应用程序，也可以是winforms实用程序应用程序，以便在各个计算机上进行分发。到目前为止，我的选择技术非常标准--T-SQL / PL * SQL，C＃/ VB，JavaScript / AJAX，CSS。
我想我正在努力确定的是，这些技术的混合在不久的将来会在我的工具箱中最有效/最有用吗？
答案 0 :(得分：14)
既不是时尚，也不会很快消失，但实际上我只希望看到大多数.NET开发者经常使用其中一个......
F＃和ASP.NET MVC之间存在很大差异; F＃是一种功能语言 - 这在一些场景中具有许多优点，但对于大多数业务线编程，诸如C＃之类的通用语言通常更有用。然而，从了解编程的功能性样式（尤其是不可变性）中可以获得很多东西。我看了F＃，我希望它能改进我的C＃，即使我从未在F＃中编写任何生产代码。幸运的是，感谢代表和lambdas，C＃可以以功能的方式使用，即使它不是正式的FP。
然而，ASP.NET MVC是一个非常不同的野兽; MVC（更一般地说）是一种已知的，已建立的和可信的模式：或者另一种方式：对很多人而言，它使ASP.NET终于有意义;我完全希望在明年能够很多使用ASP.NET MVC。
答案 1 :(得分：8)
我发现在一个问题中将函数式编程和MVC混为一谈非常奇怪;我发现它们没有任何关联，除了它们都超过30岁并且在他们的社区中非常成熟。因为我对函数式编程有所了解，所以我会对此发表看法。
功能性编程已经有近50年的历史了，虽然尚不清楚它是否会成为主流但尚不清楚。显而易见的是，功能语言已经充当了孵化器，然后为最终进入maintstream语言的功能提供了基础。一些例子：
从长远来看，在您的工具箱中使用功能技术将使您成为更好的程序员。或者正如Eric Raymond所说，学习Lisp。 （Lisp和Haskell都充满了强大的新想法，这些想法将使你的头脑以不同的，无与伦比的，但有用的方式爆炸.F＃更多地是来自功能语言的最佳验证思想的整合，与.NET框架结合。在2009年初，它似乎最有可能成为主流。）
答案 2 :(得分：6)
这些天我在SO上看到了很多这样的事情。 （有关示例，请参阅here，here和here。）
According to Wikipedia，Lisp是目前仍然常用的第二种最古老的编程语言（被Fortran击败）。功能编程不再是晶体管，鼠标，计算机显示器，硬盘驱动器，或者实际上是个人计算机的概念，在1958年Lisp创建时都没有出现过这种情况。功能性编程确实是功能性的。编程在典型的商业环境中可能不是特别有用，但它的上升和下降的普及水平并不会使它成为一种时尚，也不会使它成为玩具。对计算科学有敏锐认识的程序员理解，函数式编程不是一个发明，而是一个发现 - 深入洞察计算的基本本质。
更重要的是，如果编程是你的日常工作（而不是真正的激情），F＃是浪费你的时间吗？从某种意义上说，它可能不会变得非常受欢迎，包括在你的简历上。值得注意的是，如果你花时间去学习F＃，但是你的同事都不能理解你的工作，那么选择它作为开发工具可能会带来更多的弊大于利。这仍然不会使它成为一种“时尚”。 ：）
至于MVC，现在已经存在了很长时间 - 可能已经十多年了，但我还没有跟踪。它不是银弹，也不难掌握;这只是另一种发展模式。值得注意的是，MVC不是标准技术，甚至也不是一个非常明确的技术。有许多不同的方法来解释MVC，我甚至冒昧地说，有不止一种正确的方法来做到这一点。
MVC恰好对Web开发特别有用，因为Web应用程序往往会有非常混乱的前端代码（支持所有这些不同的浏览器是一种巨大的痛苦），而您最不希望的是让您的业务逻辑陷入困境不必要的前端。与F＃不同，学习MVC并不浪费时间，即使编程严格来说只是一天的工作，因为如果你发现自己正在使用Web应用程序，坚持MVC（即使只是松散地遵守它）可以节省你的屁股从专业的尴尬。
答案 3 :(得分：4)
至于MVC，它是在1979年推出的。我记得在1988/89时间框架内我职业生涯第一次在Aldus Persuasion for Windows（Powerpoint的一次性竞争对手）中实施它。 MVC框架在RIA应用程序中风靡一时，例如基于Adobe Flex的Web编程（Cairngorm，Mate，PureMVC等）。
在我的公司，我们的第一个Flex应用程序没有作为MVC完成，但我们对模型有多个视图。它变得一团糟。我们对MVC进行了重构，让开发人员的生活变得更好。
据我所知，只有那些尝试通过任何各种Web框架在服务器端实现MVC的人才会抱怨MVC。 Fallacies of Distributed Computing会告诉他们，做MVC是一个坏主意，其中表示渲染层被网络连接的鸿沟分开。分布式MVC和分布式对象一样糟糕。
使用RIA网络应用程序，例如基于Flex的应用程序，MVC完全在客户端完成 - 正如79年在Smalltalk图形工作站中引入的那样。然后，RIA客户端仅使用异步服务调用和/或消息传递与服务器端进行通信。
对于一个只做了一个单独的CRUD表单的应用程序，那么是的，MVC可能有点矫枉过正。但对于具有相当复杂性的丰富GUI应用程序，MVC仍然是一种非常明智的模式。
答案 4 :(得分：2)
开发代码中函数式语言的实际使用完全取决于您编写的域。正如其他答案中所述，对于经典的“业务线”应用，如果您已经了解C＃，那么您很可能很快就会切换到F＃。
但是：
答案 5 :(得分：1)
不，他们不是时尚。不，人们不认为这些成为C＃/ VB和OOP的潜在替代品。如果节省时间或金钱，人们就会使用它们。
我认为你必须要求赶时髦的行动，看看其他聪明人会兴奋，或闭上眼睛，希望风暴在几年后过去。有些技术会坚持，有些则不会。 MVC和OO一样古老，functional programming和编程一样古老。
答案 6 :(得分：1)
完全没有。
功能编程语言已经存在了几十年。
将模型编程为“MVC”实际上是一种设计模式，并且现在有很多框架使用它。
这里可能唯一的新事物就是你的观点。你不知道他们存在，或者他们是如此广泛地使用，直到他们来到MS世界。
我的第一份工作是在2000年使用Apple comp的WebObjects Framework。用它开发很容易。
答案 7 :(得分：1)
功能编程作为一种范例具有许多优势： 它提供了许多与面向对象设计在小型团队中工作时相同的优势（数据封装，多态性，代码可移植性......） 由于数据的不变性和无状态性质，它不容易出错。 线程更容易。
答案 8 :(得分：1)
我不会谈论MVC的网络应用程序的可行性......对于我们这些开发框架的人来说已经概述了明确的模式 - 这只是另一种皮肤相同的方式。我从来没有在ASP.NET的整体情况上苦苦挣扎，所以认为MVC以某种方式使其更简单通常是用词不当。它可能对一种方法有用，但不是所有方法 - 因此属于工具箱中的另一种工具。
我们真的需要另一种工具吗？
答案 9 :(得分：0)
我确信C＃和VB将会永远存在......但是也会有很多人在使用新技术。他们将能够用更少的代码完成更多工作，您将能够使用已有的代码完成更多工作。所以不要担心这将是一场公平的斗争。
即便如此......学习更多东西会让你更好地编程......所以由你决定！
我说的是，如何学习更多的语言，知道每种语言能够做什么，然后使用所有这些信息来制作更好的代码。但如果你花费同样的时间控制一种语言，那么你的希望就可以了。
答案 10 :(得分：0)
从我对函数式语言的（极端）基础知识来看，它们作为开发人员在我们的未来可能占有很高的地位。许多聪明人评论说，由于处理器没有变得更快，因此需要使用更多内核。因此，并行编程将变得更加主流。函数式语言适用于并行任务，因为它们不维护状态（有效地消除了与并行编程/线程相关的大多数常见问题，例如锁等）。
有关此特定点的更多信息，我想引导您参阅讨论可变/不可变数据的this article，并比较c＃和f＃代码段。