阅读更多

ServiceFramework是一个敏捷、快速、富领域模型的Java MVC 框架,其设计理念是让用户真正能够用最简单的方式解决80%的问题,这是框架应有的原则和价值。但目前很多Java框架为了追求框架本身的完美和扩展性而忽略了这些原则。

 

项目地址:https://github.com/allwefantasy/ServiceFramework

 

ServiceFramework 是为了快速开发而生的,其非常强调开发的高效性,其开发效率可以比肩Rails(不相信?可以体验一下):

 

  • 拥有Java界最简单、非常高效且真正的富Model层
  • Controller层含有便利的函数库、简洁高效的验证器和过滤器
  • 简单但实用的View层,天然支持JSON、XMl格式输出

因此,ServiceFramework更加适合移动互联网后端开发,这也是该框架的主要定位。

 

ServiceFramework的特性

 

目前大部分互联网应用是以数据为中心的,尤其是关系型数据库。所以如果能简化数据操作,便能有效减少代码。

 

所以我们参照Rails ActiveRecord 对模型类做了完善的充血实现。这其中绝对没有因为Java是静态语言导致的一些限制而做任何妥协。后面示例我们可以看到这一点。

 

核心优势是,Model方面真正实现了Java的充血模型,Query使用了ActiveRecord的风格。相信我,没有任何妥协。举个例子:

 

从 Form 到 Model 再到 DB:

 

Order order = Order.create(params());
if(order.save()){
  render(ok())
}
else{
  render(HTTP_403,"参数错误");
}

  

下面是一个很优秀的、被Play所推荐的ORM框架Ebean的Query Interface。调用方式如下:

 

Ebean.find(Order.class)  
                .fetch("details")  
                .setMaxRows(100)  
                .where().eq("status",Order.Status.NEW)  
                .order().desc("id")  
                .findList();  

 

说说几点:

 

  1. 模型类还是被人操作来操作去,比如需要Ebean操作Order 模型。
  2. 链式关系比较诡异,有层级关系。比如 where()下有eq()等。

再看看ServiceFramework的query interface:

 

 List<Order> orders = Order.where("status=:status",map("status",Order.Status.NEW))
                            .joins("details")
                            .limit(100)
                            .order("id desc")
                            .fetch();

   

实际应用中通常会这样使用:

 

@Entity
  class Order extends Model
  {
     public static JPQL status_new(){
       return where("status=:status",map("status",Order.Status.NEW));
     }
  }

  List<Order> orders = Order.status_new()
                            .joins("details")
                            .limit(100)
                            .order("id desc")
                            .fetch();

   

简单直观,非常自然地以SQL关键字区分,没有任何学习成本,都是按程序员最直观的方式进行。

 

其实不仅仅是Model层,controller层的设计也极尽简化。我们也对过滤器(拦截器)做了重新实现,这不同于一般的(如Struts2)的实现。同时我们还提出了一个理念,在Controller层应该提供一个函数库,就像PHP那样。当然,我们现在只是提供一些比较实用的函数。但是以后会慢慢添加。

 

此外还有一些小特点,譬如:

 

  • 一站式,不需要你整合各个框架;
  • 随时clone随时使用,看十分钟wiki便能着手开发;
  • 你不用考虑项目结构;
  • 你不用考虑如何分层;
  • 你不需要考虑配置文件,我们提供一个统一的配置对象供你使用;
  • 我们尽量使用一些最佳实践来组织项目。比如使用IOC做基础。这意味着,你大部分类都会自动被容器所管理。

使用后你会发现,该框架将Rails的灵活性带到了Java平台,欢迎Rails开发者回归Java。^-^

 

项目地址:https://github.com/allwefantasy/ServiceFramework

 

 

29
12
评论 共 106 条 请登录后发表评论
46 楼 axhack 2012-08-15 20:22
不错,一直在找java版的rails。支持。
45 楼 key232323 2012-08-15 15:53
为什么我总觉得“贫血型”的开发模式更适合大规模和大型应用?——EBean或者其他**,有一个sql方便?如果java支持多行字符串(顶Groovy),是不是就没那么多链式操作了——有筒子们赞同的么?
44 楼 java_user 2012-08-15 15:48
做移动互联网应用的还会用关系数据库?
many2one,one2one这个都是过度产品吧
43 楼 hoarhoar 2012-08-15 15:37
daxiong921 写道
allwefantasy 写道
hoarhoar 写道
从简介上来看,我也感觉有些类似play。


很多朋友看到这个框架,都说能看到play的影子。我这里也提下play和ServiceFramework的差异。
应该说play是非常的rails化,并且非常的完善,从数据迁移到异步支持。但是对一个互联网应用,很核心的是数据操作。play在这一点却没有发力。直接推荐使用EBean或者JPA(hibernate)完事。当然play添加了一些模型静态方法比如Blog.find("where name='java'")来方便用户操作,但是没有做彻底。而EBean等还是典型的贫血模型。
而ServiceFramework则在这一方面做了比较大的努力。如果你看了 ServiceFramework的Wiki 文档,你会发现ServiceFramework 的ORM是异常简洁的,包括关联关系配置。



直接在play的基础上开发呗。现在play在国内也有一部分用户基础了。play 1官方说停止升级,直接从play 1弄来做另一个分支嘛。这样用户接受度会更高。

这个想法真的非常好,楼主试试呗,修改play1.25的Model部分,这个群众基础更好,更多的人会对play比较放心,可能更好推广。
42 楼 daxiong921 2012-08-15 15:05
allwefantasy 写道
hoarhoar 写道
从简介上来看,我也感觉有些类似play。


很多朋友看到这个框架,都说能看到play的影子。我这里也提下play和ServiceFramework的差异。
应该说play是非常的rails化,并且非常的完善,从数据迁移到异步支持。但是对一个互联网应用,很核心的是数据操作。play在这一点却没有发力。直接推荐使用EBean或者JPA(hibernate)完事。当然play添加了一些模型静态方法比如Blog.find("where name='java'")来方便用户操作,但是没有做彻底。而EBean等还是典型的贫血模型。
而ServiceFramework则在这一方面做了比较大的努力。如果你看了 ServiceFramework的Wiki 文档,你会发现ServiceFramework 的ORM是异常简洁的,包括关联关系配置。



直接在play的基础上开发呗。现在play在国内也有一部分用户基础了。play 1官方说停止升级,直接从play 1弄来做另一个分支嘛。这样用户接受度会更高。
41 楼 allwefantasy 2012-08-15 14:35
zhuixinjian 写道
我比较关心Cache这一块怎么做,命中率的问题.

充分利用Model的callback 接口,比如AfterUpdate,AfterSave等,可以很好的实现对象缓存.....
40 楼 allwefantasy 2012-08-15 14:34
guojch 写道
争论了多年的充血模型的第一个不错的Java实现,支持,希望能好好发展下去,做的更好!

谢谢 您指出了精华之处....另外就是对 AR 的Query Interface. 我一直觉得这是一个非常优秀的查询接口。
39 楼 zhuixinjian 2012-08-15 14:23
我比较关心Cache这一块怎么做,命中率的问题.
38 楼 guojch 2012-08-15 14:18
争论了多年的充血模型的第一个不错的Java实现,支持,希望能好好发展下去,做的更好!
37 楼 mistbow 2012-08-15 13:46
allwefantasy 写道
damoqiongqiu 写道
对于这种东西我已经吐槽无力了,就路过一下子,好吗

好吧......


这东西都是谁用谁知道的 没用过 也不能说它不好啊
36 楼 allwefantasy 2012-08-15 13:41
damoqiongqiu 写道
对于这种东西我已经吐槽无力了,就路过一下子,好吗

好吧......
35 楼 damoqiongqiu 2012-08-15 13:35
对于这种东西我已经吐槽无力了,就路过一下子,好吗
34 楼 allwefantasy 2012-08-15 13:33
lief8888 写道
没觉得像rails,跟没觉得简单了,还是java框架的老套路。不喜欢只是简单的把xml换成annotation,实现了类似activerecord功能就像rails了,感觉rails里边最精华的coc你们并没有贯彻的很好,总得说来就是和其他java框架比起来在同一水平线,没觉得有什么优势。

啊,啊,啊.....
没像rails就正常了。我们看重的是,框架是不是真的能让你写程序更加的舒服,能不能高效的开发。
看下Wiki哦。就ORM实现层面来说,我个人认为 Annotation是比belongs_to
之类的更有优势更简洁的。
rails 的方式:
class BlogComment < ActiveRecord::Base
  belongs_to :blog
  belongs_to :user
 end


ServiceFramework 的方式:
@Entity
class BlogComment extends Model {
  
  @OneToMany
  private Blog blog;

  @OneToMany
  private User user;

}

更重要的是,在代码量相差不大的情况下,Java还具有良好的代码提示

如果你觉得只是Model层类似AR那么高效的话,你还可看看Wiki文档中的Controller层,也是有很多简化的地方的。

至于coc,我建议您还是画上几分钟看看Wiki
33 楼 lief8888 2012-08-15 13:11
没觉得像rails,跟没觉得简单了,还是java框架的老套路。不喜欢只是简单的把xml换成annotation,实现了类似activerecord功能就像rails了,感觉rails里边最精华的coc你们并没有贯彻的很好,总得说来就是和其他java框架比起来在同一水平线,没觉得有什么优势。
32 楼 sdujq 2012-08-15 13:07
易卡螺丝君 写道

花点时间学习下ruby是会死还是会怀孕啊 真的那么难?

我决定开始学Ruby了
31 楼 fjjiaboming 2012-08-15 12:58
...新手, 和语言爱好者, 折腾人士喜欢的..


项目连目前MAVEN构建都不是.
30 楼 fjjiaboming 2012-08-15 12:56
object link 风格.
29 楼 zhouyu260 2012-08-15 12:14
专为移动后端定制,这句话挺吸引人的,天然支持JSON、XMl格式输出,不错,最近想做一个程序,服务器端采用爬虫抓取数据+jsoup解析数据,后端数据输出感觉用这个框架挺适合的
28 楼 allwefantasy 2012-08-15 10:59
youjianbo_han_87 写道
放到Google Code上去啊。。。。。

已经在 github 上了。 https://github.com/allwefantasy/ServiceFramework
27 楼 youjianbo_han_87 2012-08-15 10:47
放到Google Code上去啊。。。。。

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Global site tag (gtag.js) - Google Analytics