Log4Classicning

好读书 不求甚解 每有会意 便欣然忘食

Guice获得Jolt2007最佳框架奖
2008年3月10日

曾经有一段时间Alex不遗余力的（^_^）向我推荐Guice框架，我当时只用Spring做过一个练手项目，对Spring都还不是非常熟悉，正心急火燎，所以就暂时搁置下来了。而最近在寻找不同于Spring+Hibernate+Struts2的另一套轻量级方案，基本上锁定了Guice+OpenJPA+Wicket，我叫它J2EE Web Develop without XML。

已经用Guice和Wicket整合做了一个留言本的示例程序，Guice确实非常简单，全部Annotation标记。可以说Annotation之于XML配置文件的好处就是Guice之于SpringIoC的好处，当然从另一方面来说，Annotation之于XML配置文件的缺点Guice难免也都沾上了。不过，在绝大多数时间，我们接触的小规模的项目中，这个缺点几乎不是什么缺点。虽然我非常不能认同在接口上加上ImplementedBy这样的Annotation，但是绝大多数时候这么做也不会造成太大的问题（仅仅是缺少一点美感而已，接口怎么能知道谁实现了它），因为对于那些可能造成问题的情况，也许我们从一开始就不会使用Guice，而是用Spring甚至EJB3。

不过跟Spring一整套几乎涵盖了大半个Java世界的整合方案相比，Guice就显得单薄了一些。其它倒也无所谓，关键是Guice上的事务管理成了一个比较麻烦的问题，享受过Spring AOP带来的便利后，真要自己实现一个还真得费一番脑筋设计（话说，这个过程其实很有趣。我觉得这就是Java带给我的乐趣，而Grails、Django一类的框架上似乎很难感受到这种自己设计的乐趣了。个人观点，扯远了）。不过现在这似乎也不是问题，前两天我GoogleGroup上看到一个叫作Warp-persist的框架为Guice提供了这部分的支持，但是我还没有尝试，因为他的网站被GFW了。（有话说，据说整个Warp Framework是一套很赞的Java Web开发框架）

目前正在准备开始一个Guice+OpenJPA+Wicket的小型项目，由于没有容器、没有Guice的事务支持，JPA的EntityManager和Transaction都要自己管理，是个挑战啊。

最后，强烈向大伙推荐路遥的小说《人生》，我今天用了一天时间看完了，很有感触。

评论: 6 | 引用: 0 | 分类: Tech | Tags: Java   JavaEE   framework   Guice  
« Winter新增发布到twitter类网站的功能近些年做过的东西（部分） »
  • quote 1.alex
  • 呵呵 暴露了我geek的本性 warp的官方站可以通过这个访问：
    http://www.browsequeen.com/index.php?q=uggc%3A%2F%2Fjjj.jvqrcynl.pbz%2Fubzr

    warp包含了warp-persist，warp-mvc和warp-servlet。warp-persist已经进入stable状态，warp-mvc是一个tapestry的guice修改版，warp-servlet是对guice-servlet的加强。warp支持声明性事务管理。

    接口是公共扩展点，我也无法接受@ImplementedBy注记，还是用Module配置依赖比较好。
    我觉得guice最大的优点在于：类型安全、静态配置优先、简洁小巧。配置文件应该只用来配置面向用户的会在运行时变化的信息。
    现在感觉guice（ioc框架的共同问题）比较大的问题是一旦使用，实现就和框架绑定了，如果是hibernate或者struts这种框架，可以用一个facade把具体实现隔离在接口后面，但ioc框架本身就是用来绑定接口的，这种方法就失效了。所以我现在的想法是ioc框架、aop框架这种“横断性”的框架应该只在应用层（集成层）使用，业务层最好不使用任何框架，留出接口给高层组装就好
  • 2008-3-10 23:50:11 回复该留言
  • quote 2.Classicning
  • http://www.classicning.com/blog
  • 你给的地址我还是访不了，打开是一个拿国旗的小人

    ioc对代码的绑定我觉得也有限吧，比如我用spring就基本可以保证在业务层的代码里就看不到任何spring的东西，用guice就不行，这是annotation的问题。
    再一个hibernate可以用dao挡住，但是struts也行吗，我倒是觉得到了struts这层就无所谓了。
  • 2008-3-11 8:35:10 回复该留言
  • quote 4.alex
  • 汗 我是用gladder上的 这个地址应该是可以的……

    我的想法是业务层存放的是业务逻辑，业务逻辑的特定实现都放在应用层。在业务层不知道spring，也不知道guice。在应用层需要知道所有的框架，然后用框架实现业务层留出的接口。
    数据访问所需的操作可以用一个接口声明出来（可以在应用层，也可以在业务层），然后hibernate实现这个接口，然后用框架绑定。
    struts一般不需要封装，不过要封装也是可以的，将各个action所需要的信息和服务用一个接口声明出来，action只知道这个接口，应用层的其他部分实现这个接口。

    guice的配置信息在module中配置，这和xml配置是一致的。guice的客户端需要使用@inject标记，spring的客户端需要setter方法（如果我没理解错的话:)）其实也是类似。后者是一种命名约定，前者是显式的声明。看个人喜好吧:)
  • 2008-3-11 12:46:36 回复该留言
  • quote 5.Classicning
  • http://www.classicning.com/blog
  • Spring确实可以做到让代码不知道Spring的存在，这是没问题的，但是Guice光import annotation就侵入不少了。当然这个也不是Guice的问题，Annotation本身就存在这样的问题。

    spring用setter方法注入也是遵守JavaBean的约定的，这个无可厚非，况且Eclipse NetBeans什么的都能自动生成这样的代码（就是重构起来有问题）。Guice用Modue编程式的绑定依赖关系，我觉得小项目里还是很方便的，但是如果规模大了就不敢保证了。说到头还是Guice把依赖关系写死在代码里，其实也就是区别了Spring和Guice的规模不同，Guice还是适合一些小的灵巧的项目，如果Service层的东西多了，总觉得Guice有些力不从心，况且散布在各处的Annotation也不像xml清晰。

    各有所长吧。
  • 2008-3-11 13:44:58 回复该留言
  • quote 6.alex
  • 我觉得配置在xml文件里和配置在Module类里是一样的，不算是写死吧，因为spring的配置文件也是启动时Context时一次性读入的。
    我不是很明白，用spring客户端应该也需要用spring的context的吧…… 这和@inject类似
    在其他地方，都看不到spring或者guice的吧，除非使用@ImplementedBy
    alex 于 2008-3-11 15:49:27 回复
    这个问题讨论下去就没边了……
    spring和guice核心的区别在设计哲学上，这有一个guice自己的说法：
    http://code.google.com/p/google-guice/wiki/SpringComparison
    现在还是spring比guice更加实用一些，主要是guice要求jre在1.5上，这个会遇到很多阻力。不过guice是从google最大的项目google adwords出来的，项目规模应该是没问题的，但是还需要时间继续发展。
  • 2008-3-11 14:32:22 回复该留言

发表评论:

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。

Search

站点统计

  • 文章总数:745
  • 评论总数:2630
  • 引用总数:4
  • 浏览总数:5693
  • 留言总数:42
  • 当前主题:ClassicningDailyLog Style
  • 当前样式:footoo

网站收藏

图标汇集

  • Creative Commons License
  • Widgetize!
  • visitor stats

Powered By Z-Blog 1.8 Spirit Build 80722

2004 - 2007 Classicning.com. 苏ICP备06039259号.