我想尝试在F＃中开发ASP.NET和ASP.NET MVC应用程序。我喜欢使用功能语言，在我看来，功能范例更适合HTTP和Web而不是命令式编程（当然F＃可以同时执行这两种操作）。
我只是打算为某些个人项目尝试F＃，但我希望最终F＃将被视为适合商业ASP.NET项目的C＃的有效替代品。
目前在ASP.NET中使用F＃有什么陷阱和粗糙边缘？一个明显的缺点是F＃比C＃更加模糊，因此F＃的代码示例和经验丰富的程序员更少。
我应该注意哪些其他潜在问题？
答案 0 :(得分：7)
就个人而言，我是F＃的忠实粉丝。我的NDjango解析器/渲染引擎是用F＃编写的。
但是尝试用F＃做所有事情可能很困难。要添加到尚未存在的内容列表中：
不支持视觉效果 设计师 - 既不是网络也不是 的WinForms。你可以写 手动适当的代码，当然
无代码完成
在F＃中调试可能是一个挑战，特别是因为匿名关闭
由于类型推断，编译器诊断可能会产生误导 - 一个拼写错误可能会在远处产生深远的影响
我最大的烦恼是'文件订单问题'规则。您必须指定文件的编译顺序
绝不是完整列表。另一方面，人们可能希望在最终版本中解决其中一些问题。
尽管存在所有列出的（和未列出的）问题，我喜欢用F＃编程 - 有时候它会对编码提供一个非常清晰的视角，我已经开始在我的C＃代码中使用一些受F＃启发的技巧。
只是不要发疯了
答案 1 :(得分：5)
这是家庭项目还是工作？如果是为了工作，你需要考虑其他人投入和维护代码的能力 - 与有能力的C＃人员相比，没有太多的F＃开发人员。
答案 2 :(得分：3)
mmmmm f＃，另一种敢说它名字的白肉。为此，F＃先生将会说“它的未来！”。至于陷阱......嗯！，有什么陷阱，你只需要创建没有chuff和Objects的东西。
C＃很棒，它有它的位置。但正如你正确指出它不适合网络编程。在这个问题上，ASP.net提供的事件和镜像都没有。
走低。想想HttpHandlers和REST。你不需要MVC的东西。它和理念而不是产品。
前端GUI与后端无关。你真的需要ASP.net吗？ JSON / REST / POX .....考虑到这些，开发你的中间层，你应该没问题。远离WCF它的适当和讨厌。
可维护代码的注释。小道火焰。为什么你不想做什么。如果他们不像你那样思考，那么你想要他们吗？
当我在项目上工作时，想法驱动产品而不是技术，当然不是群众或暴徒。大型组织仅仅出于一个原因迎合暴民，它与推进艺术和欧元的所有事无关。
消息和管道是我在当前气候中使用的。当环境支持事件时，事件是很好的，但是Web的异步性质是否适合考虑具有时钟滴答的处理管道并检查事情是否已经完成。
.Net对一件事情有好处。中间层有DB和逻辑。至于前面。使用别的东西。更多webby。
为什么只有F＃引入全场最佳射击比赛。有很多可供选择的PHP，python，ruby，clojure，haskell等......
F＃不仅仅是它，而是它所代表的，是多核多线程，多进程的新时代和绝望时代的旧思维方式。
我曾经听过的一首歌说：“我不关心他们的不同想法 不同的想法对我有好处“
答案 3 :(得分：1)