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
您还没有登录,请您登录后再发表评论
26 楼 allwefantasy 2012-08-15 10:11
你不用考虑如何分层；
我看到这个就知道不是一般人能用的。
通常你会发现大部分项目的结构基本是一致的。比如 MVC类的框架，都会有四层,View/Controller/Service/Model .我们提供了较为标准的组织结构。你只要相应的去填充目录。当然，我们并不排除你们自定义这些目录和结构。但是遵循这些规则总是能帮你省下不少事情的。
25 楼 allwefantasy 2012-08-15 10:08
该框架脱胎于一个内部的项目。性能上个人认为不会有问题。这点放心。至于复杂的企业应用是不适合的。就如我Wiki中说的，我们定位于 后台服务，通过json,xml等进行通信。尤其适合 移动领域 后端，需要快速的开发以及丰富的库支持。
24 楼 a_alter 2012-08-15 09:58
你不用考虑如何分层；
我看到这个就知道不是一般人能用的。
23 楼 allwefantasy 2012-08-15 09:54
很多朋友看到这个框架，都说能看到play的影子。我这里也提下play和ServiceFramework的差异。
应该说play是非常的rails化,并且非常的完善，从数据迁移到异步支持。但是对一个互联网应用，很核心的是数据操作。play在这一点却没有发力。直接推荐使用EBean或者JPA(hibernate)完事。当然play添加了一些模型静态方法比如Blog.find("where name='java'")来方便用户操作，但是没有做彻底。而EBean等还是典型的贫血模型。
而ServiceFramework则在这一方面做了比较大的努力。如果你看了 ServiceFramework的Wiki 文档，你会发现ServiceFramework 的ORM是异常简洁的，包括关联关系配置。
22 楼 Sam1860 2012-08-15 09:51
21 楼 pinnerc 2012-08-15 09:44
从简介上来看，我也感觉有些类似play。
支持
20 楼 hoarhoar 2012-08-15 09:31
从简介上来看，我也感觉有些类似play。
19 楼 mianhuaman 2012-08-15 08:58
18 楼 mianhuaman 2012-08-15 08:56
17 楼 witcheryne 2012-08-15 08:40
JAVA玩meta programming? 动态性? 良好的社区? 这些都没 我干嘛还选山寨货
花点时间学习下ruby是会死还是会怀孕啊 真的那么难?
笑, 也请坐高端喷...
Java玩meta programming?
看看Groovy, 基于java, Groovy -> 编译 -> *.java -> 编译 -> *.class
http://groovy.codehaus.org/
社区? Google 中仅仅输入 Groovy 关键字就够找到一堆活跃社区, 国内: GroovyQ
最后一句:
如果作者不了解rails, 怎么能写出一个让大神您,觉得山寨的东西?
如果说山寨
谈面向对象, smalltalk笑了,
谈ruby, Lisp笑了
P.S:
能不能介绍一下使用案例, 项目由来? 这个会让人比较放心.
16 楼 daxiong921 2012-08-14 23:26
15 楼 易卡螺丝君 2012-08-14 23:08
JAVA玩meta programming? 动态性? 良好的社区? 这些都没 我干嘛还选山寨货
花点时间学习下ruby是会死还是会怀孕啊 真的那么难?
14 楼 java_user 2012-08-14 22:58
13 楼 allwefantasy 2012-08-14 22:29
事务目前是action级别的。这意味着一个action方法是就是一个事务边界。
12 楼 tarsean 2012-08-14 22:21
11 楼 allwefantasy 2012-08-14 22:16
rails也好，node.js也好，都只是在其自己的某些领域做的比较好。Java依然在很多方面具有非常大优势。企业应用，cpu密集类的程序等等。当然，这不是我们要讨论的问题。
10 楼 易卡螺丝君 2012-08-14 22:03
这是很多人都会提出的疑问。我在这里一并做解答。希望之后大家不要在这方面纠结。
首先举个反例：
如果你是一个Java工程师，Java某框架也有AR，然后你觉得这个AR因为最早是Rails发明的，于是你又去学习Rails，接着把原来的工程改为Rails 项目。
这是不符合逻辑的。
通常，每个语言都有自己的适用范围。但是这不影响语言之间的学习。如果某个语言的某个框架在某一方面(领域)总结出了一套行之有效的(通常我们称之为最佳实践)规范，那么他就应该值得另外一些语言或者框架学习并提高相应的开发的效率而摒弃掉原来的，没必要因为是模仿学习了别人而觉得肯定没有对方的好。
语言之间的互通可以通过http,web service等很好的解决的。但只是因为某些组件或者框架而导致过多语言混杂在一起，这其实是有学习和维护成本的。通常人们希望一个一致的clean的解决方案，所以借鉴其他语言的优秀思想然后使用自己的语言实现是很有必要的。
你不能要求因为需要使用某个框架或者库而使得项目混杂过多语言，你也无法要求A语言使用者的用户因为一个库而去学习B语言，也不能因为A语言在某一方面使用不便而必须忍受这种不便，对吗？
9 楼 allwefantasy 2012-08-14 21:58
这是很多人都会提出的疑问。我在这里一并做解答。希望之后大家不要在这方面纠结。
首先举个反例：
如果你是一个Java工程师，Java某框架也有AR，然后你觉得这个AR因为最早是Rails发明的，于是你又去学习Rails，接着把原来的工程改为Rails 项目。
这是不符合逻辑的。
通常，每个语言都有自己的适用范围。但是这不影响语言之间的学习。如果某个语言的某个框架在某一方面(领域)总结出了一套行之有效的(通常我们称之为最佳实践)规范，那么他就应该值得另外一些语言或者框架学习并提高相应的开发的效率而摒弃掉原来的，没必要因为是模仿学习了别人而觉得肯定没有对方的好。
语言之间的互通可以通过http,web service等很好的解决的。但只是因为某些组件或者框架而导致过多语言混杂在一起，这其实是有学习和维护成本的。通常人们希望一个一致的clean的解决方案，所以借鉴其他语言的优秀思想然后使用自己的语言实现是很有必要的。
你不能要求因为需要使用某个框架或者库而使得项目混杂过多语言，你也无法要求A语言使用者的用户因为一个库而去学习B语言，也不能因为A语言在某一方面使用不便而必须忍受这种不便，对吗？
8 楼 易卡螺丝君 2012-08-14 21:39
7 楼 ray_linn 2012-08-14 21:31