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
您还没有登录,请您登录后再发表评论
106 楼 shuzheng5201314 2015-10-10 17:07
105 楼 allwefantasy 2013-03-05 10:26
View层集成Freemarker之类的其实也是很方便的。我最近也参考了多个View层渲染引擎，但是都觉得过于复杂以及不够易用。
104 楼 fnet 2013-03-04 23:24
103 楼 bennyee 2012-09-12 16:51
语言无优劣之分，具体问题具体对待。所以楼上各位大可不必吵得不可开交。
就此框架的定位而言，很大程度上简化了移动平台服务器端开发。 简介高效，使用方便，这不正是大家所需要的嘛。 何必纠结细节，如果觉得有不完善的地方，完全可以参与优化嘛！ 不要哔哔，只说不练。 本来就是开源项目嘛。
我的下一款应用服务器端会试用下楼主的框架，以观后效。
楼主加油！
102 楼 damoqiongqiu 2012-09-10 23:07
Java 语言天生残疾。
我去，没文化的喷子又出现了
偶玩 Java 的时候，你还在幼儿园沙子和尿玩呢。井底蛤蟆，你见过多大个天。小白一只。
大胆！再敢装大拿，本程抓住你抽你
懒得理它了，SB样儿。
101 楼 iminto 2012-09-10 21:53
Java 语言天生残疾。
我去，没文化的喷子又出现了
偶玩 Java 的时候，你还在幼儿园沙子和尿玩呢。井底蛤蟆，你见过多大个天。小白一只。
大胆！再敢装大拿，本程抓住你抽你
100 楼 allwefantasy 2012-08-21 17:25
充血模型中充斥着RDB的操作概念，我要用NoSQL怎么办！！
OOD哪里去了？面向领域模型的设计哪里去了！！
就为了不写ORM配置么？真心的倒退。个人不看好
ORM本身也是面向RDB的。对于NoSql也是有解决方案的。比如Rails里面有个mongoid
http://mongoid.org/en/mongoid/index.html
,就是用ServiceFramework中的那套QueryInterface 操作mongodb的。至于mongoid的接受情况我专门做了一个调查：
http://ruby-china.org/topics/4890
从评论看，还是颇被人接受的。
99 楼 linliangyi2007 2012-08-21 11:47
充血模型中充斥着RDB的操作概念，我要用NoSQL怎么办！！
OOD哪里去了？面向领域模型的设计哪里去了！！
就为了不写ORM配置么？真心的倒退。个人不看好
98 楼 flashing 2012-08-20 10:25
程序员有两种论调，fullstack和anti-framework的，我觉得楼上这个论调是anti的，因为gorm是基于hibnerate的，思想上也是，如果能理解hibnerate，就能理解这个。单纯比较grom一个查询细节就像比较jpa和mybatis一样，个人觉得这种代码风格并非是什么重点，适应了就ok了如果你一直用hibnerate，可能连适应都不需要。
至于说学习成本和利用现有知识以及无缝集成现有的东西，我觉得反倒是这几点是选择grails的原因，hibnerate和springwebmvc的所有知识在这里直接就可以以更简单的方式使用。
而且真正体现生产力的还真不是这一两个查询，看看grails的绑定，校验，command类，map和list结合闭包的使用，dsl的配置，到处可见的ioc，绝对便捷的标签和模板，一切都是和without ejb那本书里面的理念一脉相承，就是体现生产力。
最后，还是那句话，java太严谨了，而且缺乏一些关键特性，所以不适合快糙猛的需要，即使你用了觉得更直观的查询api（说实话这个直观还是个见仁见智的事儿），那也不过是茴香豆的几种吃法之一；我们需要的是喝酒吃肉----所以还是换门脚本语言比较合适。
我这`迁移`词汇可能用的不大合适。我的含义是，公司假设初期主要积累都在java方面，而且大家都对java熟悉。如果就此`迁移`到譬如说ruby(或者groovy)上，未知风险增加，即程序员能否快速切换到新的语言，开发过程会不会遇到问题，并且这种切换是需要一个熟悉groovy或者ruby的人来进行指导。所以说，很多情况切换一个语言并不是一件容易的事情。因此，如何完善现有平台的工具和框架，努力提高生产效率，也是非常重要的。这也是为什么开发ServiceFramework的一项原因。
很多语言的本身方面的弊端是可以通过语言自己的某些方式避免的。我们举个例子，Java的集合类和hash一直不好用。而其他语言都是通过
list = ['a','b','c'] \\ hash = {'abc':'google','java':"yes"}这种形式。非常的直观方便。但是Java也是可以做到简洁的。通过`静态导入`+ 不定参数，就可以做到非常的直观。譬如
List list = list('a','b','c'); \\ hash = map( 'abc','google' 'java','yes' )你看，也是可以非常方便的。
所以很多东西都是相对的。如果你愿意不断改善，在享受原有的益处，也是能不断提升的。
当然，我还是赞同下面一个想法：
假设条件允许，很多web项目还是应该转义到动态语言提供的框架中。这包括基于虚拟机平台的或者完全不同的平台，例如ruby等。
真心话groovy的迁移没那么痛苦，很简单，也可能看了一段时间scala看倒胃口了，scala太理论化了概念太多了，回过头看groovy反倒觉得这玩意巨简单。
我说的list和map不仅仅是声明简单与否（btw那个map的声明虽然有创意但是一个代码格式化全糟而且还丧失了变异期检查的优势），比如def mmList = userList.collet{it.sex=='F' && it.age<25}，这种类似的瑞士军刀，怎么说呢，不恰当的比喻有点pythonic范儿？或者if (user != null && user.getName() != null) {...}对比if (user?.name) {...}我想哪个写起来更愉快不言而明的，要知道一个真正的好程序员6-7成时间在处理错误。
最后，如果你愿意行动，很多事情你会发现没那么困难，尤其在观望了那么久之后。。。而且groovy不会让你放弃任何以前的东西，比如类库什么的直接拿过来就可以用，这应该算是一个better better java。
97 楼 allwefantasy 2012-08-20 09:55
程序员有两种论调，fullstack和anti-framework的，我觉得楼上这个论调是anti的，因为gorm是基于hibnerate的，思想上也是，如果能理解hibnerate，就能理解这个。单纯比较grom一个查询细节就像比较jpa和mybatis一样，个人觉得这种代码风格并非是什么重点，适应了就ok了如果你一直用hibnerate，可能连适应都不需要。
至于说学习成本和利用现有知识以及无缝集成现有的东西，我觉得反倒是这几点是选择grails的原因，hibnerate和springwebmvc的所有知识在这里直接就可以以更简单的方式使用。
而且真正体现生产力的还真不是这一两个查询，看看grails的绑定，校验，command类，map和list结合闭包的使用，dsl的配置，到处可见的ioc，绝对便捷的标签和模板，一切都是和without ejb那本书里面的理念一脉相承，就是体现生产力。
最后，还是那句话，java太严谨了，而且缺乏一些关键特性，所以不适合快糙猛的需要，即使你用了觉得更直观的查询api（说实话这个直观还是个见仁见智的事儿），那也不过是茴香豆的几种吃法之一；我们需要的是喝酒吃肉----所以还是换门脚本语言比较合适。
我这`迁移`词汇可能用的不大合适。我的含义是，公司假设初期主要积累都在java方面，而且大家都对java熟悉。如果就此`迁移`到譬如说ruby(或者groovy)上，未知风险增加，即程序员能否快速切换到新的语言，开发过程会不会遇到问题，并且这种切换是需要一个熟悉groovy或者ruby的人来进行指导。所以说，很多情况切换一个语言并不是一件容易的事情。因此，如何完善现有平台的工具和框架，努力提高生产效率，也是非常重要的。这也是为什么开发ServiceFramework的一项原因。
很多语言的本身方面的弊端是可以通过语言自己的某些方式避免的。我们举个例子，Java的集合类和hash一直不好用。而其他语言都是通过
list = ['a','b','c'] \\ hash = {'abc':'google','java':"yes"}这种形式。非常的直观方便。但是Java也是可以做到简洁的。通过`静态导入`+ 不定参数，就可以做到非常的直观。譬如
List list = list('a','b','c'); \\ hash = map( 'abc','google' 'java','yes' )你看，也是可以非常方便的。
所以很多东西都是相对的。如果你愿意不断改善，在享受原有的益处，也是能不断提升的。
当然，我还是赞同下面一个想法：
假设条件允许，很多web项目还是应该转义到动态语言提供的框架中。这包括基于虚拟机平台的或者完全不同的平台，例如ruby等。
96 楼 flashing 2012-08-20 09:39
程序员有两种论调，fullstack和anti-framework的，我觉得楼上这个论调是anti的，因为gorm是基于hibnerate的，思想上也是，如果能理解hibnerate，就能理解这个。单纯比较grom一个查询细节就像比较jpa和mybatis一样，个人觉得这种代码风格并非是什么重点，适应了就ok了如果你一直用hibnerate，可能连适应都不需要。
至于说学习成本和利用现有知识以及无缝集成现有的东西，我觉得反倒是这几点是选择grails的原因，hibnerate和springwebmvc的所有知识在这里直接就可以以更简单的方式使用。
而且真正体现生产力的还真不是这一两个查询，看看grails的绑定，校验，command类，map和list结合闭包的使用，dsl的配置，到处可见的ioc，绝对便捷的标签和模板，一切都是和without ejb那本书里面的理念一脉相承，就是体现生产力。
最后，还是那句话，java太严谨了，而且缺乏一些关键特性，所以不适合快糙猛的需要，即使你用了觉得更直观的查询api（说实话这个直观还是个见仁见智的事儿），那也不过是茴香豆的几种吃法之一；我们需要的是喝酒吃肉----所以还是换门脚本语言比较合适。
不过前提是你不想抛弃jvm以及对fullstack，也就是spring+hibnerate的全集成方案仍然有爱，否则还是换rails或者python吧。
贴的这点代码片段和grails几乎一样，但是语法级别java太严谨了，在现在这个快糙猛的时代的确有点落后，未来大趋势还是脚本语言做产品，编译语言做核心库。
btw:
1.groovy和grails是springsource现在在全力推，我相信springsource的人品和理念。
2.play还是和其名字一样，的确就是play。。。虽然简单也是美。。。不过和rails，grails，django等不是一个级别的，而且scala学起来还是有点痛苦的。
一个有益的讨论。之前也了解过groovy.这里两个问题来讨论：
1 应该用groovy之类的动态语言吗？
如果能用基于JVM的动态语言自然就用动态语言，包括相应的开发框架。动态语言绝对是提高生产率，而且让程序员更舒心的一种东西。但是前提是能迁移过去并且有相应的有经验的开发人员指导迁移。
2.我刚才看了下Grails的orm和query interface.我个人依然认为Arel提出的QueryInterface是最优的。
为什么这么说呢？
一个模式的设计好不好，在易用的大前提下，还有两个判断标准：
[ 额外的学习成本大不？]
[能否利用现有知识]
[ 新的功能是否能无缝的集成进去甚至用户都没感觉到]
Grails的 orm的
这种声明方式暂且不提(其实不如Java原生的OneToMany之类的注解来的直观，当然ServcieFramework也在模型校验器以及过滤器等方面使用了这种变量声明的技巧)
我们只看看query interface的设计。
Blog.where('name='google'').order('id desc').fetch();这种以关键字为方法名的链式操作，可以有效利用代码提示。绝对比使用hash的key-value的方式来的方便。比如：
ServiceFramework的query interface (其实就是模范ruby 中 Arel的设计)第一没有任何学习成本。一般用户看完一眼就新林神会了，因为就是简单的sql语句，只是通过关键字隔开，最后框架帮你拼起来。
第二呢充分利用了大家对sql语句的掌握。第三呢，我们看个例子
Blog.join(" blog_comments").fetch();我在查询博客的时候同是把评论查出来，第一直觉的sql语句应该是：
blog_comments是Blog 里的一个属性。我join它，直觉上就应该出来了。
也就是很直观的提供了新的功能，不需要你再把join关系手动写上。最后查询出来的结果也是符合orm精神的，blog对象里面有blog_comments集合。
95 楼 allwefantasy 2012-08-20 08:34
不过前提是你不想抛弃jvm以及对fullstack，也就是spring+hibnerate的全集成方案仍然有爱，否则还是换rails或者python吧。
贴的这点代码片段和grails几乎一样，但是语法级别java太严谨了，在现在这个快糙猛的时代的确有点落后，未来大趋势还是脚本语言做产品，编译语言做核心库。
btw:
1.groovy和grails是springsource现在在全力推，我相信springsource的人品和理念。
2.play还是和其名字一样，的确就是play。。。虽然简单也是美。。。不过和rails，grails，django等不是一个级别的，而且scala学起来还是有点痛苦的。
一个有益的讨论。之前也了解过groovy.这里两个问题来讨论：
1 应该用groovy之类的动态语言吗？
如果能用基于JVM的动态语言自然就用动态语言，包括相应的开发框架。动态语言绝对是提高生产率，而且让程序员更舒心的一种东西。但是前提是能迁移过去并且有相应的有经验的开发人员指导迁移。
2.我刚才看了下Grails的orm和query interface.我个人依然认为Arel提出的QueryInterface是最优的。
为什么这么说呢？
一个模式的设计好不好，在易用的大前提下，还有两个判断标准：
[ 额外的学习成本大不？]
[能否利用现有知识]
[ 新的功能是否能无缝的集成进去甚至用户都没感觉到]
Grails的 orm的
这种声明方式暂且不提(其实不如Java原生的OneToMany之类的注解来的直观，当然ServcieFramework也在模型校验器以及过滤器等方面使用了这种变量声明的技巧)
我们只看看query interface的设计。
Blog.where('name='google'').order('id desc').fetch();这种以关键字为方法名的链式操作，可以有效利用代码提示。绝对比使用hash的key-value的方式来的方便。比如：
ServiceFramework的query interface (其实就是模范ruby 中 Arel的设计)第一没有任何学习成本。一般用户看完一眼就新林神会了，因为就是简单的sql语句，只是通过关键字隔开，最后框架帮你拼起来。
第二呢充分利用了大家对sql语句的掌握。第三呢，我们看个例子
Blog.join(" blog_comments").fetch();我在查询博客的时候同是把评论查出来，第一直觉的sql语句应该是：
blog_comments是Blog 里的一个属性。我join它，直觉上就应该出来了。
也就是很直观的提供了新的功能，不需要你再把join关系手动写上。最后查询出来的结果也是符合orm精神的，blog对象里面有blog_comments集合。
94 楼 key232323 2012-08-19 22:37
不过前提是你不想抛弃jvm以及对fullstack，也就是spring+hibnerate的全集成方案仍然有爱，否则还是换rails或者python吧。
贴的这点代码片段和grails几乎一样，但是语法级别java太严谨了，在现在这个快糙猛的时代的确有点落后，未来大趋势还是脚本语言做产品，编译语言做核心库。
btw:
1.groovy和grails是springsource现在在全力推，我相信springsource的人品和理念。
2.play还是和其名字一样，的确就是play。。。虽然简单也是美。。。不过和rails，grails，django等不是一个级别的，而且scala学起来还是有点痛苦的。
恩，需要jvm才groovy的——如果python/ruby大公司能在他们上面积累投资，它们应该是更给力的。
只用java，再怎么所谓的COC，糅杂各种设计模式，就开发效率来说（做产品、业务型系统）和动态语言还是没法比的
93 楼 flashing 2012-08-19 21:20
不过前提是你不想抛弃jvm以及对fullstack，也就是spring+hibnerate的全集成方案仍然有爱，否则还是换rails或者python吧。
贴的这点代码片段和grails几乎一样，但是语法级别java太严谨了，在现在这个快糙猛的时代的确有点落后，未来大趋势还是脚本语言做产品，编译语言做核心库。
btw:
1.groovy和grails是springsource现在在全力推，我相信springsource的人品和理念。
2.play还是和其名字一样，的确就是play。。。虽然简单也是美。。。不过和rails，grails，django等不是一个级别的，而且scala学起来还是有点痛苦的。
92 楼 hoarhoar 2012-08-19 19:05
91 楼 damoqiongqiu 2012-08-19 09:43
中国人是优等民族，你看之前的帖子很多是关心技术和框架本身的，然后出现了这个人【ray_linn】，然后一切就变了，不信你仔细看帖子，还有那个人在论坛里面的表现，每次都是这个样子的
对于小白，骂就是为了他好
【小白】的含义是什么？你觉得你就不是【小白】？
个人觉得人品好更重要
你丫挺的觉得自己牛逼，但是别人看你丫就是喷子+傻逼，明白没？
能看得懂我说的吗？
不能的话多看几遍。
90 楼 ray_linn 2012-08-19 09:29
中国人是优等民族，你看之前的帖子很多是关心技术和框架本身的，然后出现了这个人【ray_linn】，然后一切就变了，不信你仔细看帖子，还有那个人在论坛里面的表现，每次都是这个样子的
对于小白，骂就是为了他好
89 楼 damoqiongqiu 2012-08-19 09:17
中国人是优等民族，你看之前的帖子很多是关心技术和框架本身的，然后出现了这个人【ray_linn】，然后一切就变了，不信你仔细看帖子，还有那个人在论坛里面的表现，每次都是这个样子的
88 楼 hoarhoar 2012-08-19 07:58
87 楼 theoffspring 2012-08-18 22:29
Java 语言天生残疾。
我去，没文化的喷子又出现了
偶玩 Java 的时候，你还在幼儿园沙子和尿玩呢。井底蛤蟆，你见过多大个天。小白一只。
玩的时间长短和掌握的程度有关系吗
mvc, orm， 能不能折腾点新玩意，天天折腾这些没营养的框架，每一个能成事的，还不如好好弄弄django,rails,就是.net mvc也比这些狗皮倒灶的强
你就这个水平？mvc,orm是很重要的东西，.net的不过也是模仿java的东西，rails研究过，写得够烂的，约定的东西太多，乱七八糟的。
你这种大脑短路的绝不适合搞it.要是 rails 那么烂，这个所谓的serviceframework 干嘛需要在标题里写上效率堪比rails? 你那所谓的研究就是写2个 hello,world 就以为自己精通这个，精通那个。。
你怎么像我肚子里蛔虫似的？怪不得你有如此高论，就凭你这么主观的说法，这么些你果然是在“玩”。