您在Scala / Lift中开发的经验是什么？

3 回答

• 28

  • 我现在正在Scala做我的大部分事情 . （我应该提一下，我认为Scala是不久前发明轮子以来最好的东西 . :-D）

  在我看来，它是真正允许人们选择最佳方法来完成任务的唯一语言，而不会在（更多）面向对象和（更多）功能方法之间产生不必要的分歧 .

  看看之前声称类似的语言，我基本上可以看到两个相互竞争的语言设计阵营：

  • 来自面向对象方面的那些看到函数式编程最近获得了一些牵引力并认为"Well, we don't really understand that functional thingie, but let's add some fancy syntactical sugar to our language, so we can claim it is functional too!"（例如：Java，Python）

  • 然后是功能方面的人，他们认为"Well, our functional approach is far superior to anything else and that object-oriented nonsense is annoying, but let's put some additional keywords into our language, that will make our language escape academia for sure!"（例如：F＃，OCaml）

  Scala的设计师统一了来自双方的许多方法，并创造了一些精心设计的语言 - 这是我的拙见 - 与其他语言的最大区别，后者决定采用“弗兰肯斯坦”方法进行编程语言设计 .

  • 仅使用Lift做了一些较小的东西，只有Rails和Django的表面经验，我不得不承认，大部分时间我都想知道为什么Lift中的某些东西与我的预期不同，这是因为我的期望有缺陷，而且Lift的方法更优越 .

  Lift当然不是“Scala的简单介绍”，但学习Lift如何工作几乎和学习Scala一样有 Value .

  能够拥有一个没有任何逻辑的“干净”视图的能力是对其他框架的一个很大的改进，这些框架声称相同，但没有达到它 . Scala的XML文字支持使得验证响应的良好性能成为可能：编译器将在编译时证明您只向客户端发出格式良好的XML .

  • Lift是可行的技术，目前唯一真正的方法，如果你想构建外观，感觉和行为像“真正的”桌面应用程序的Web应用程序，而无需自己编写疯狂的代码 .

  回复于 2024-04-19T18:53:32+08:00
• 7

  我正在研究我的第二个Lift应用程序 - 它在Lift的最佳位置非常强烈 - 非常实时，很多并发性 .

  第一个我们在与DB层摔跤几天之后就畏缩了（现在它变得更好了，我被引导相信），然后去了Play / Scala . 这最大化了我们团队的现有知识，并使截止日期成为可能 . 但是，一旦我们的项目变得适度大（PermGen不断运行 - 这是Scala编译几乎无处不在的问题），并且在不同的地方手动处理方法调用参数和位置安全等问题，热代码重新加载几乎停止了 . 在网站上相当繁琐 . 当它完成时我们很高兴 - 就像我倾向于找到Rails 1一样，随着项目规模的增加，速度的增加也会缩小，到最后，它就像在Velocity中工作一样乏味且容易出错 . Spring / XML无论如何） .

  这一次，我们一直致力于研究Lift如何做它所做的事情以及正确的做事方式 . 这意味着通过邮件列表进行大量的随意浏览（几个版本的讨论通常仍然相关），最重要的是团队的新精神 . 有必要非常强烈地内化这个座右铭：

  “这种感觉很难反复 . 我敢打赌他们做得更容易 . ”

  到目前为止，Lift从未让我们失望过 . 顺便说一句，我不是在谈论Sitemap和列表连接语法之类的东西 - 你必须对功能Scala有一个很好的处理，否则你将无法阅读源代码甚至配置你的应用程序 .

  这就是说它不是疯狂的IO monads或者其他什么东西，只是你在Scala的几周内会发现的一些常见的习语 .

  对我们来说最大的问题是编译周期缓慢 . 跳船需要大约20秒钟：运行我们的项目，这是一种与Play不同的感觉（当它正在工作时）热编译你所有的东西 . 另一方面，我们实际上是在我们的一个开发者抱怨它的那一天，并且它确定尽管Play技术热门编译它，但页面仍然需要12秒才能在开发模式下加载 . 所以没有巨大的损失，只是觉得有点慢到必须跳到命令行 .

  Lift可以让你做很多事情，我们的应用程序中有很多地方（因为它是可用的），我们已经说过“是的，我们真的希望将该实时更新直接更新到该页面的所有观看者，而不是他们后来发现它们已经过时（想想你发布的所有时间）同时向SO上的某个人提出同样的答案） . COMET无处不在，事实证明 - 它不是一个专业用例，它是事情应该运作的方式 . 而Lift让它变得非常简单 .

  我们也喜欢强大的，可编程配置的安全模型 - 一旦我们将思维模式转换为“我们必须将每个位置列入白名单，并指定必要的入口条件”，我们从未看到另一个会话问题 - 您知道，那些您认为用户会遍历某条路径，从而知道一大堆参数？比如，一个有效的用户名，一个感兴趣的领域或其他什么？ （我故意模糊） . 这可能是关于有状态框架的尴尬事情之一，当用户点击页面时，您将希望具有可用状态，而不是（例如）要求所有状态在每个请求中被携带 .

  我从Lift的重新拍摄中得到的结论：

  这很值得 . 不只是构建您正在尝试构建的应用程序，而是构建您不需要的应用程序 .

  有很多头疼，但不是很多代码 . 当它工作时，它确实有效 . 它快速，干净，而且对于它在浏览器和服务器之间工作的所有奇迹，我从来没有看到它变得困惑 .

  回复于 2024-04-19T18:53:32+08:00
• 9

  我在Lift开发企业财务应用超过6个月，我是JAVA程序员前者 . 我注意到了几点，可以帮助你：

  • 我写了明显更少的代码行（great example）

  • 在电梯周围，有一种非常友好的community . 他们总是试图提供实质性的答案 . 我没有任何糟糕的经历 . 即使他们愿意为Lift中的新功能提供新建议 . 他们批准了我的两条建议！

  • 每隔6到8周宣布一次新的稳定次要版本的Lift . 每两周定期举办一次新的里程碑 .

  • Lift是Web应用程序的绝佳框架 . 你可以阅读七个main features的升力 .

  • Lift默认ORM模块 - Mapper不适用于具有大量外键和约束的大型和高级数据库模型 . 我们不得不使用Squeryl .

  我无法想象我现在必须返回JAVA代码 . 但我的小建议是尝试编写一些简单的应用程序，你会看到 .

  回复于 2024-04-19T18:53:32+08:00