航行日志

看到一篇Scala使用状况的文章，写的非常中肯

发表于 | 分类于

转自：http://scalagroup.group.javaeye.com/group/topic/19125

项目早期采用BlazeDS+Spring+Hibernate的模式开发，开发过程中写服务的时候感觉用Spring的HibernateTemplate不是很方便，虽然spring很好的替你处理了Hibernate的Session生命周期管理和事务，但是象下面这样的代码



Java代码

  1. public void insertUser(final User user) {
  2. getHibernateTemplate().execute(new HibernateCallback() {
  3. public Object doInHibernate(Session session) throws HibernateException {
  4. session.saveOrUpdate(user);
  5. return null;
  6. }
  7. });
  8. }

写起来总觉得不爽。服务中大量使用HQL查询，但是HQL需要拼凑字符串，就算使用Hiberante的Criteria ，代码写起来可读性太差。早就想封装一套比较好用一点的DAO框架，在看过了一些第三方封装之后，这个念头就打消了，个人感觉不论再怎么封装，限于Java语言的表达能力，用起来也不是简便的。适逢scala2.7大力推广时期，有兴趣了解了一下，感觉比较适合来封装一套DAO和查询语法的DSL，便着手尝试了一下，期间经历了一些波折，主要对scala语法的不太熟悉，以及与java一些类库的相互调用不太方便，费了一些时间。最终封装出来的效果还是比较理想的，用起来也感觉比较方便，举两个列子：

更新用户信息


  1. val user = User(123)
  2. user.name = ….
  3. …..

  4. user.UPDATE


一个复杂的查询


  • new Q_Task {

  • SELECT(*,
  • status, priority, actor.name, creator.name,scheduled,
  • messageBox.*, milestone.name, milestone.dueDate,
  • sharePolicy.id)
  • WHERE {
  • actor.id === …
  • deleted === false
  • if(…){
  • OR {
  • status === D_TaskStatus.RUNNING.id
  • status isNull
  • }
  • }
  • OR {
  • scheduled === false
  • AND {
  • scheduleStartTime.isNotNull
  • DATE_DIFF(scheduleStartTime, new Date) < 0
  • }
  • }
  • }
  • ORDER(modifyTime.desc)
  • }

    • 查询语句完全是类型安全的，字段可以语法提示，拼写错了，在编译期间就可以检测的到，WHERE里面可以写的很复杂，可以根据if条件来动态的生成WHERE条件项，这些用Java语法是很难做到和实现的。

    因为scala是新生事物，不敢贸然大规模使用，开始尝试一两个小服务用scala来写，借助于scala语法的便利性，原来java 十句话可以完成的逻辑，scala三四句就可以搞定了。初期是java服务和scala服务共存的方式，运行过一段时间后，感觉scala写的服务也比较稳定，不存在系能上的问题，开始大面积用scala来写服务，包括把原有的一些用java写的服务重构为Scala实现（用scala写的比较精简，便于以后维护）。现在，几乎不愿意用java来写服务代码了，语法太罗嗦，开发效率也不高。包括一些底层的框架，能不用java就尽量用scala来写，写起来还是比较省心的。

    说一些scala使用过程的碰到的问题以及一些可能解决办法

    1 比较高的学习曲线，没有接触过函数式编程概念一上来很容易被scala那些怪异的操作符和语法搞晕，而且又多出来很多新概念，消化吸收需要花费一段时间。语法太过灵活，用好了事半功倍，用烂了祸患无穷。个人感觉值的投入精力学一下，用好了，会带来开发效率的提升。

    2 与原有的java类库不象宣传中的那样可以完全方便的互操作，scala中的集合框架自成一套体系，当访问java集合类的时候需要转换一下才能方便使用，因为大量的java第三方库都是使用的java的集合框架，这一点用起来还是比较麻烦的，不过scala2.8通过隐式转换已经很好的解决了这个问题，使用2.7的话，自己封装一下做一下隐式转换也是可以解决这个问题。

    3 序列化支持的不好，在远程服务调用模式下，需要把服务端的一些模型类序列化到客户端，标准的javabean没有任何问题，用scala写模型的话，会用到一些scala的集合类，这些都不太好序列化。在和BlazeDS集成的时候，通过扩展BlazeDS的序列化能力，碰到scala集合类，转换为java的标准集合类可以解决这个问题。

    4 编译器的编译速度还有待提升，做一个小项目，写几十个scala类还感觉不到编译速度慢的问题，如果是上百上千个scala类，编译速度就成大问题了，可以把项目按依赖关系拆成几小块，单独编译，只编译变化的部分。

    5 ide的开发环境还不是很成熟，官网推荐的那三个ide各有所长，但总的来说离成熟的标准还有一段距离。早期用eclipse很长一段时间，后因内存耗用和频繁的界面卡死等问题，改用IDEA Community版，代码提示没有eclipse的全，但比较稳定，可以自动导入，重构，格式化，这些都是eclipse欠缺的。对netbean不太感冒，没有正经用过，代码提示，重构等做的也可以，因项目比较大，scala类比较多，netbean用ant脚本来编译，改动一处，所有的类都要重新编译一遍（也可能是对netbean不熟，或许有选项可以支持增量编译吧），速度实在不能忍受。

    6 scala中大量使用闭包，而scala闭包是通过java内部匿名类的方式来实现的，由于java虚拟机的限制，内部匿名类的名称是根据代码行号变化的。开发期间如果想通过字节码热部署的方式，来不重启虚拟机，实现快速开发是不太可能了，除非你的逻辑里面不使用闭包，这几乎是不可能的。

    7 scala 和 spring的集成还是比较顺畅的，scala写的服务类中，通过@autowire方式可以方便的注入java的服务类，需要spring3.0版本

    8 scala 中还没找到比较好用orm框架，目前还是依赖hibernate，又对其做了一下封装。lift略了解了一点，感觉作者封装orm的思路和自己想法相去甚远，也就没有在深入了解下去，有实际用过的可以发表一下感受。

    9 因为scala过于灵活，对于同一个项目组来说，最好约定一个通用的规范，否则真会天下大乱了。

    10 scala还没有完全实现内置的反射机制，想利用反射来做一些高级特性方面的应用，还比较困难。

    11 scala2.8 不兼容2.7编译后的字节码，即便2.7的代码想用2.8来编译一下，由于语法上的一些差异，有些地方还需要做一些重构，现在想把2.7的代码升级的2.8就比较头疼。

    12 如果做一个新项目，建议还是完全用scala来做，java+scala混合编程的方式感觉还是不太方便，java能做的，scala完全都可以做到。用scala会牺牲一点性能，但差距不是太大，况且性能的问题，需要的是合理的系统架构，有效的利用缓存机制，而不仅仅只靠语言本身的执行速度。