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
您还没有登录,请您登录后再发表评论
6 楼 allwefantasy 2012-08-14 20:23
此话怎讲？^_^
5 楼 allwefantasy 2012-08-14 20:23
我在文中已经对EBean和ServiceFramework的ORM进行了对比，本质上EBean是对ActiveRecord进行"形"的模仿，当然这已经简化了查询接口，但本质上依然是按dao的思路去做的，通过某个类对Java模型类进行操作。而ServiceFramework则是完全按照AR的思路去实现了。目前主要查询接口都已经实现。已经能满足你80%的需求了。其实Play对 Rails模仿的非常到位，但是ORM则没有怎么发力，直接使用EBean或者JPA.
不管如何模仿或者创新，最终的目的都是为了提高生产效率。所以大家不要认为这又是Rails的翻版或者什么的 呵呵。
4 楼 allwefantasy 2012-08-14 20:17
spring roo 的magic是通过aspectj在编译的时候织入代码，这样就使得你在IDE发现很多你没有声明过的神奇方法。但是我并不认为这会带来多大的优势。实际上Java的框架最需要的是简化ORM模型，而充血模型则能很好的解决这类问题。另外Query Interface也是一个很重要的东西，因为你会发现你的应用大部分都是query查询,而我认为 ActiveRecord的query interface应该是最佳实践了，所以ServcieFramework也基本实现额这套规范。
3 楼 yq5858588 2012-08-14 18:59
2 楼 badboy560 2012-08-14 18:05
1 楼 mistbow 2012-08-14 18:02