Ameba Framework 初章

jopen 10年前

Ameba 一个构建在J2EE标准之上的全栈框架,以后可能包含更多,从售前竞标到发布部署整条流水。

前言

个人是比较懒的一个人,所以也懒得写文档,博客,但是我承认这是一个好习惯,记录自己的成长和备忘。但是,身为程序员的我,还是把懒的精神发挥的有些淋漓尽致了,也不知道这个系列能持续多久,碎碎念多久。这个系列应该没有什么技术性的东西,应该都是使用和设计上的。对于技术我还是比较狂热的,但是,不等于每个人都有这种想法,而我试图做的事情就是掩盖这些技术,提供好用的接口,面向更多的程序员们,更加亲民的框架。所以,这个框架不会有过多的彩头,不会像很多国产框架那般小巧,而且因为是全栈式的,反而会很大,下面就会说这个问题,鱼和熊掌的故事我们一会儿谈谈。既然写了博文就是做好了接受“教育”的准备,所以呢,请大家畅所欲言(真的有人看的话,表示是一个毫无存在感的人)。目前框架还处于0.1.6的版本,还有很多特性没有完善,或者这样的需求不足以去实现。当然,我解决的都是几年来我所遇到的问题,不一定适合任何人。框架的架构有一些大刀阔斧的变动,和我们现在所使用的层次结构出入比较大,可能一些人无法接受,但事实上,我们真的需要那么多层次,那么多接口么?在我的答案中是不需要的!快速稳定的版本迭代,要比接口设计更加重要,我们大多数时候一个接口对应一个实现,那么这样的接口真的有存在的意义么?为并不存在的虚假需求预留接口真的有必要么?再者,面对RESTful的结构,不同的service实现有必要么?通过不同的URI寻找不同的实现才是最好的选择吧?这部分应该由客户端去控制,而我们所做的应该是对应用户角色控制好权限逻辑,只要对不同service所提供的对外服务加入安全控制就足够了,剩下的交给客户端去选择,这些年服务的操碎了心,应该适当的减轻工作了。

设计目标

框架从最开始的产生就是为了解决开发效率、项目管理、团队协作和扩展问题,当今的终端过于繁多,产生了服务接口多次重构、更改或添加新接口供新终端使用的现象,所以,我需要一个可以对外提供服务接口,同时可以对外提供友好的UI界面直接提供给客户的东西。就这样,RESTful出现了,我固执的相信JAX-RS就是我想要的。我选择了jersey作为基础,那个时候jersey还是1.x,不支持对象的直接传输,bean的验证,甚至过滤器还没有完善。我整合了guice,利用AOP实现了对象到json字符串,form表单的转换,bean的验证,安全控制等等。在之后接手了别的项目就没有搞下去。一年后,jersey升级到了2.x,这真的是一次革命性的升级,实现了我所需要的所有功能,内置的IoC,filter的完善等等,这真的是令人振奋的事情(说实话,oracle接手java之后有很多的变革发生,java不再那么的土鳖了)。然后我利用业余时间重写了之前的框架,重新开始一个项目,就这样Ameba产生了!我整合了HTTLEbean,实现了一些基础的东西,包括静态文件处理、Model的增强、一个配置文件等等,之后公司又忙了起来,到处“救火”,直到今天,中间又停滞了半年多。不过,前一段时间因为一些原因,我又开始利用业余时间去完善框架,向playframework看齐,将框架拆分出许多模块,加入了开发模块、详细的错误信息提示、热加载、事件系统、ebean升级到4.x(play还是2.3.x,前一段时间ebean的开发者和play的开发者还在讨论ebean 4.x和play2的模块化整合)、完善了模板与模板的自动寻找、简单的模块系统等等。

Ameba的目标是核心功能只提供RESTful+模板+ORM(必然,你也无法剥离其中的任何一项,但是可以禁用模板的特性,或者使用你自己的模板),其他功能全部采用模块的形式插入进来,并且模块是自我配置的,而主配置文件可以覆盖任何模块配置。这点和play略有不同,但是主旨基本一样,不过我没有想过要复制play,而是想要比play更好,play脱离了我们java程序员,比较倾向于scala,而且怎么高兴怎么来,不会去管什么Java规范(标准)问题,而Ameba是亲和J2EE规范的(虽然他是Java SE规范),建立在JAX-RS标准之上,对其进行扩充粘合,让开发者也采用模块的方式开发,并且不产生太多的额外学习成本。而目标和play也有很大出入,play更前向于敏捷开发,写较少的代码,还是在框架层面,而Ameba定位在流程上,从售前竞标到上线部署,整个流程,当然Ameba也推崇敏捷开发。所以,Ameba的网会铺的很大,实现点会很多,说实话我不确定是否能坚持下来。

关于大小、重量和第三方类库

Ameba采用了jersey、logbak(groovy配置)、AKKA、Ebean等等第三方类库,所以注定Ameba的身材很感人,足有40M+,这其中包括了一个NIO的服务器,和各种第三方工具。

较大的类库有

  1. groovy-all-2.3.4.jar 7.3M 用于配置logbak,对于groovy编写配置文件真是大爱,不愿意割舍。
  2. scala-library-2.10.4.jar 7.1M AKKA依赖的东西,play也会有这个,因为play用akka作为最基础的架构
  3. akka-actor_2.10-2.3.4.jar 2.6M
  4. ecj-4.4.jar 2.3M 用于动态编译JAVA类,这个在后期的resource设计工具中会有用,是工作流和规则引擎的基础
  5. guava-17.0.jar 2.2M 大爱的google工具包,大小十分感人。。。
  6. druid-1.0.7.jar 1.8M 国产的连接池,这个不用介绍了把 oschina 就是这个
  7. avaje-ebeanorm-4.1.4.jar 1.6M
  8. h2-1.3.173.jar 1.6M 好吧,其实这个用于开发的,没人在生产使用,jdbc的包跟这个大小差不多,甚至更大
  9. jackson-databind-2.4.1.jar 1.1M jackson,这东西也不小。。。。
  10. jersey-guava-2.11.jar 962.9K 这个其实是和guava重复的,没办法jersey自己搞出来自己用的

说说为啥不自己写呢?

  1. 我没有那个能力
  2. 确实能给开发人员提供便利,就算我不导入,开发人员也会使用其中很多把?
  3. 我为什么要重复造轮子?
  4. 没那么多时间去做前辈已经做了的事情,成本太大

种种原因我决定自己写不太实惠,所以Ameba的身材难免有些感人,但还不至于臃肿,我相信这些成熟的框架不可能写一堆没用的代码。而且既然是全栈,提供好用的接口,身材注定不会小多少,全栈就要考虑很多扩展问题,全面性的问题,所谓鱼和熊掌不可兼得。体积小必然是亮点,但是体积小也不意味着好用和快速。框架的所有类库已经是精挑细选了,我也表示无奈。

关于使用那些事儿

结构

Ameba Framework 初章

我想我也不用叙述什么,结构大体就这样,没有什么约定,只不过要使用maven。

模型

Ameba Framework 初章

我不知道该怎么描述它,模型在框架的设计中是最重要的地方,承载着数据交互的重要环节,前后端的数据交互,数据库存储,参数验证,VO等等,它是框架的灵魂部分。

资源

Ameba Framework 初章

这是一个资源的声明,返回一个HTTL渲染的模板,并且在用户已经登录的状态下会跳转到首页 SigninedRedirect 注解关联的是一个过滤器,用于判断是否已经登录,然后跳转到首页

Ameba Framework 初章

一个简单的注册,EmailUtil是email模块提供,使用HTTL渲染内容,前端直接传输JSON对象,自动封装成SignUpEmail对象,框架自动验证数据。

User.withFinder().where().eq("email", signup.email).findRowCount();

withFinder为框架自动增强,User父类实际并未实现这个方法,sql查询是linq的形式。

Ameba Framework 初章

这个是高级一些的,自己构造response

一个user的持久化

User user = new User();  user.email="xxx@xx.com";  user.password="123456";  user.withPersister().save();

应用程序模式

框架内置了三种模式,开发模式,生产模式,测试模式,每一种对应不同的模块和功能以及日志。开发模式(需要ameba-dev模块)提供精确的报错信息的UI展示,详细的日志输出,热加载等。

热加载

没什么花头,就是像play那样子,刷新页面就是最新的东西或直接显示报错地方的代码。不过现在内部类热加载有些问题

发布的目录结构

Ameba Framework 初章

现在还没有提供servlet的容器实现,将来会有的,现在是跑在grizzly上面,一个高性能的NIO框架,没有之一

conf/application.conf

Ameba Framework 初章

所有的配置都在这一个文件里面,当然,你还可以创建dev.conf ,product.conf ,test.conf这些配置文件会在启动的时候根据应用程序模式自动加载

最后

实在困的不行,也不知道你们看的懂不?大概就这样,还有好多东西没说,和后续要做的事情,具体看github吧

https://github.com/intelligentcode/ameba/issues