Warp framework - 一个相当有前途的Java轻量级Web开发框架

好咚咚啊。

讨论一下哈。

我比较反感在domain代码里用Provider<Foo>。引入一些annotation也就罢了，毕竟单元测试的时候可以无视这些@的。而且即使将来放到Guice外面用，annotation的ClassNotFoundException也是无害的。但是用了Provider和实现FactoryBean也就相隔不远了。而且，读代码时候也有点别扭，明明我要的就是一个Foo，为什么需要注射一个Provider<Foo>? 单元测试也相应的麻烦一些。

所以我一般在需要注射一个所谓lazy的组件的时候，都是做一个lazy proxy。这样，domain里面还是注入Foo，只不过在module里面给注射了一个proxy。

那个第一个dynamic finder的例子，为什么会有{return null;}这个东西？难道不是一个接口么？

还有那个Person find(@Named("firstName") String name);

这个@Named是Guice的那个么？不过这里面应该用不到binding annotation了吧？

return null在他的blog例子里出现了，是写在类里的，不是接口。

@Named是guice的那个，需不需要绑定，还真不晓得。

正好工作中需要用一个非常轻量的rest框架。看了restlet，感觉作者受servlet毒害太甚，什么Request, Response，这么一层一层的包装不累么？

然后看warp，看到这个示例，觉得不是很清楚，拿出来讨论一下：

@URIMapping("/blog/{subject}")
public class ViewBlog {
  private Blog blog;

  @OnEvent @PreRender
  public void init(String subject) {
    this.log = listBlogs.getBlog(subject);
  }
}

不满意的地方：
1。从rest的角度，我总觉得@URIMapping不如叫@Resource合适。这是命名问题。
2。什么东西一旦有生命期，有状态变化，有事件，利马这复杂度就上去了。这个什么@OnEvent @PreRender用的着么？还明显强迫对象不能immutable。


我希望的理想状况应该是：

@Resource("/blog/{subject}")
public final class ViewBlog {
  private final Blog blog;

  @Inject public ViewBlog(@RestParam("subject") String subject) {
    this.log = listBlogs.getBlog(subject);
  }
}

这样，对象还是完全遵守immutable对象规范，单一状态，线程安全，完全pojo。

从domain设计上说，每个pojo实例完全代表一个独立的资源，而不是service handler或者说transaction script模式。不明白为什么warp不这样做。

楼上说的深有体会， 像SEAM里的会话上下文， 工作区管理

再加上几个新概念，学习曲线也水涨船高。

我不这么看。这个ViewBlog类似Webwork的Action，本身是prototype的，每次请求创建，为啥就不能有状态呢？就是RoR的controller也是一样，每次请求创建controller实例。

再说@Event，这个就是Webwork里面的Interceptor的东西，起到AOP作用的，在RoR里面也有类似的Filter概念，没觉得加一个@Event怎么会复杂。

不过话说回来，在ViewBlog这个具体的例子当中，使用@Event的方式来初始化数据，的确没有必要，例子举的不恰当。

状态不可怕，可怕的是状态变迁。这个例子里面，就涉及了before initialized和initialized两个状态。而且优先使用immutable也是基本的best practice吧？Guice也是强调constructor injection的。

interceptor不会有状态变化，所以无所谓。要说这个，更象servlet的init()，老掉牙很丑陋的东西。

你说的固然有道理，但更像是一种编程味道的好恶，特别是这个例子的确举的不好。但它这样用，也不会导致代码出啥问题吧？

零配置是没了，都转向硬编码了，我看不出annotation 比配置文件好到哪里。

java体系发展到现在，我感觉应该是浓缩的时候了，这样才能到达另外一个高度。我估计很多开发者都在期盼sun出来一整江湖。

选择权往往不在程序员手里的，一般一个项目是一个团队的事，作为技术架构师或者技术经理一般作这个选择，选择的过程并不是你所说的“企图孤注一掷的寻找一种所谓的万金油编程语言，然后死抱着不放，企图用它干任何事情，眼睛里面容不下任何其他技术。”，初期一定是想听听各种人的意见，仅仅是听意见而已，实际作选择的时候要考虑很多方面，选择的过程是找平衡点的过程。当然对我来说，你的意见是比较重要的，或者说你的意见中的理念是很值得参考的。

 

话说回来，这个世界从来不是最好的技术成为最流行的技术，虽然我们朝这个方向努力，当初Hibernate的成功也算是努力的结果，但是市场格局出现很多意想不到的结果，个人以为即使是技术架构师必须要考虑很多非技术的因素，我记得有一个回英文贴的一个观点非常好，要重视这个框架背后操作的团队是谁。