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
您还没有登录,请您登录后再发表评论
66 楼 key232323 2012-08-16 16:59
Java 语言天生残疾。
我去，没文化的喷子又出现了
实话要委婉点说。。。呵呵
65 楼 daxiong921 2012-08-16 16:33
64 楼 daxiong921 2012-08-16 16:33
很多朋友看到这个框架，都说能看到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弄来做另一个分支嘛。这样用户接受度会更高。
63 楼 daxiong921 2012-08-16 16:33
很多朋友看到这个框架，都说能看到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弄来做另一个分支嘛。这样用户接受度会更高。
62 楼 daxiong921 2012-08-16 16:33
Java 语言天生残疾。
61 楼 daxiong921 2012-08-16 16:32
很多朋友看到这个框架，都说能看到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弄来做另一个分支嘛。这样用户接受度会更高。
60 楼 daxiong921 2012-08-16 16:32
Spring ROO 需要专门的 AspectJ 编译器支持。另外就是根据注解大量的生成代码我觉得不直观，不符合通常的开发方式。总之，有点麻烦。
但是我觉得Spring ROO 通过切面方式生成代码的方式非常的好。
59 楼 daxiong921 2012-08-16 16:32
58 楼 daxiong921 2012-08-16 16:32
很多朋友看到这个框架，都说能看到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弄来做另一个分支嘛。这样用户接受度会更高。
57 楼 yjc2020 2012-08-16 15:22
56 楼 allwefantasy 2012-08-16 14:13
Spring ROO 需要专门的 AspectJ 编译器支持。另外就是根据注解大量的生成代码我觉得不直观，不符合通常的开发方式。总之，有点麻烦。
但是我觉得Spring ROO 通过切面方式生成代码的方式非常的好。
55 楼 damoqiongqiu 2012-08-16 14:10
Java 语言天生残疾。
我去，没文化的喷子又出现了
54 楼 ray_linn 2012-08-16 13:52
Java 语言天生残疾。
53 楼 offbye 2012-08-16 13:17
52 楼 ray_linn 2012-08-16 11:47
Scalatra
51 楼 易卡螺丝君 2012-08-16 11:42
lift
50 楼 kimmking 2012-08-16 11:24
49 楼 key232323 2012-08-16 11:06
sql语句采用配置文件的方式来管理，配置文件本身就是支持多行模式的，类似于mybatis和bboss持久层的sql语句管理机制，
我的意思是动态语言比配置文件灵活且方便的多——我是个xml喷子，如果你说你在xml里写sql比groovy里写sql方面，我可不相信
48 楼 zhc0822 2012-08-16 10:28
47 楼 yin_bp 2012-08-16 09:13
sql语句采用配置文件的方式来管理，配置文件本身就是支持多行模式的，类似于mybatis和bboss持久层的sql语句管理机制，以bboss为例：
<?xml version="1.0" encoding="UTF-8"?> <properties> <property name="getRequesterDaoListInfo"> <![CDATA[ select r.*, o.ORG_NAME as service_requester_org_name from TD_ESB_REQUESTER r left join TD_SM_ORGANIZATION o on r.SERVICE_REQUESTER_ORG = o.ORG_ID where 1=1 #if($service_requester_code && !$service_requester_code.equals("")) and SERVICE_REQUESTER_CODE = #[service_requester_code] #end #if($service_requester_account && !$service_requester_account.equals("")) and SERVICE_REQUESTER_ACCOUNT like #[service_requester_account] #end #if($service_requester_name && !$service_requester_name.equals("")) and SERVICE_REQUESTER_NAME like #[service_requester_name] #end #if($service_requester_org && !$service_requester_org.equals("")) and SERVICE_REQUESTER_ORG = #[service_requester_org] #end order by create_time desc ]]> </property> </properties>