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();
说说几点:
- 模型类还是被人操作来操作去,比如需要Ebean操作Order 模型。
- 链式关系比较诡异,有层级关系。比如 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
46 楼 axhack 2012-08-15 20:22
45 楼 key232323 2012-08-15 15:53
44 楼 java_user 2012-08-15 15:48
many2one,one2one这个都是过度产品吧
43 楼 hoarhoar 2012-08-15 15:37
很多朋友看到这个框架,都说能看到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
很多朋友看到这个框架,都说能看到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
充分利用Model的callback 接口,比如AfterUpdate,AfterSave等,可以很好的实现对象缓存.....
40 楼 allwefantasy 2012-08-15 14:34
谢谢 您指出了精华之处....另外就是对 AR 的Query Interface. 我一直觉得这是一个非常优秀的查询接口。
39 楼 zhuixinjian 2012-08-15 14:23
38 楼 guojch 2012-08-15 14:18
37 楼 mistbow 2012-08-15 13:46
好吧......
这东西都是谁用谁知道的 没用过 也不能说它不好啊
36 楼 allwefantasy 2012-08-15 13:41
好吧......
35 楼 damoqiongqiu 2012-08-15 13:35
34 楼 allwefantasy 2012-08-15 13:33
啊,啊,啊.....
没像rails就正常了。我们看重的是,框架是不是真的能让你写程序更加的舒服,能不能高效的开发。
看下Wiki哦。就ORM实现层面来说,我个人认为 Annotation是比belongs_to
之类的更有优势更简洁的。
rails 的方式:
ServiceFramework 的方式:
更重要的是,在代码量相差不大的情况下,Java还具有良好的代码提示
如果你觉得只是Model层类似AR那么高效的话,你还可看看Wiki文档中的Controller层,也是有很多简化的地方的。
至于coc,我建议您还是画上几分钟看看Wiki
33 楼 lief8888 2012-08-15 13:11
32 楼 sdujq 2012-08-15 13:07
花点时间学习下ruby是会死还是会怀孕啊 真的那么难?
我决定开始学Ruby了
31 楼 fjjiaboming 2012-08-15 12:58
项目连目前MAVEN构建都不是.
30 楼 fjjiaboming 2012-08-15 12:56
29 楼 zhouyu260 2012-08-15 12:14
28 楼 allwefantasy 2012-08-15 10:59
已经在 github 上了。 https://github.com/allwefantasy/ServiceFramework
27 楼 youjianbo_han_87 2012-08-15 10:47