Ameba Stack - 初章
前言
个人是比较懒的一个人，所以也懒得写文档，博客，但是我承认这是一个好习惯，记录自己的成长和备忘。但是，身为程序员的我，还是把懒的精神发挥的有些淋漓尽致了，也不知道这个系列能持续多久，碎碎念多久。这个系列应该没有什么技术性的东西，应该都是使用和设计上的。对于技术我还是比较狂热的，但是，不等于每个人都有这种想法，而我试图做的事情就是掩盖这些技术，提供好用的接口，面向更多的程序员们，更加亲民的框架。所以，这个框架不会有过多的彩头，不会像很多国产框架那般小巧，而且因为是全栈式的，反而会很大，下面就会说这个问题，鱼和熊掌的故事我们一会儿谈谈。既然写了博文就是做好了接受“教育”的准备，所以呢，请大家畅所欲言（真的有人看的话，表示是一个毫无存在感的人）。目前框架还处于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产生了！我整合了HTTL，Ebean，实现了一些基础的东西，包括静态文件处理、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规范的，建立在JAX-RS标准之上，对其进行扩充粘合，让开发者也采用模块的方式开发，并且不产生太多的额外学习成本。而目标和play也有很大出入，play更前向于敏捷开发，写较少的代码，还是在框架层面，而Ameba定位在流程上，从售前竞标到上线部署，整个流程，当然Ameba也推崇敏捷开发。所以，Ameba的网会铺的很大，实现点会很多，说实话我不确定是否能坚持下来。
关于大小、重量和第三方类库
Ameba采用了jersey、logbak（groovy配置）、AKKA、Ebean等等第三方类库，所以注定Ameba的身材很感人，足有40M+，这其中包括了一个NIO的服务器，和各种第三方工具。
较大的类库有
- groovy-all-2.3.4.jar 7.3M 用于配置logbak，对于groovy编写配置文件真是大爱，不愿意割舍。
- scala-library-2.10.4.jar 7.1M AKKA依赖的东西，play也会有这个，因为play用akka作为最基础的架构
- akka-actor_2.10-2.3.4.jar 2.6M
- ecj-4.4.jar 2.3M 用于动态编译JAVA类，这个在后期的resource设计工具中会有用，是工作流和规则引擎的基础
- guava-17.0.jar 2.2M 大爱的google工具包，大小十分感人。。。
- druid-1.0.7.jar 1.8M 国产的连接池，这个不用介绍了把 oschina 就是这个
- avaje-ebeanorm-4.1.4.jar 1.6M
- h2-1.3.173.jar 1.6M 好吧，其实这个用于开发的，没人在生产使用，jdbc的包跟这个大小差不多，甚至更大
- jackson-databind-2.4.1.jar 1.1M jackson，这东西也不小。。。。
- jersey-guava-2.11.jar 962.9K 这个其实是和guava重复的，没办法jersey自己搞出来自己用的
种种原因我决定完全自己写不太实惠，所以Ameba的身材难免有些感人，但还不至于臃肿，我相信这些成熟的框架不可能写一堆没用的代码。而且既然是全栈，提供好用的接口，身材注定不会小多少，全栈就要考虑很多扩展问题，全面性的问题，所谓鱼和熊掌不可兼得。体积小必然是亮点，但是体积小也不意味着好用和快速。框架的所有类库已经是精挑细选了，我也表示无奈。
关于使用那些事儿
结构
我想我也不用叙述什么，结构大体就这样，没有什么约定，只不过要使用maven。
模型
我不知道该怎么描述它，模型在框架的设计中是最重要的地方，承载着数据交互的重要环节，前后端的数据交互，数据库存储，参数验证，VO等等，它是框架的灵魂部分。
资源
这是一个资源的声明，返回一个HTTL渲染的模板，并且在用户已经登录的状态下会跳转到首页 SigninedRedirect 注解关联的是一个过滤器，用于判断是否已经登录，然后跳转到首页
一个简单的注册，EmailUtil是email模块提供，使用HTTL渲染内容，前端直接传输JSON对象，自动封装成SignUpEmail对象，框架自动验证数据。
User.withFinder().where().eq("email", signup.email).findRowCount();
withFinder为框架自动增强，User父类实际并未实现这个方法，sql查询是linq的形式。
这个是高级一些的，自己构造response
一个user的持久化
User user = new User();
user.email="[email protected]";
user.password="123456";
user.withPersister().save();
应用程序模式
框架内置了三种模式，开发模式，生产模式，测试模式，每一种对应不同的模块和功能以及日志。开发模式（需要ameba-dev模块）提供精确的报错信息的UI展示，详细的日志输出，热加载等。
热加载
没什么花头，就是像play那样子，刷新页面就是最新的东西或直接显示报错地方的代码。不过现在内部类热加载有些问题
发布的目录结构
现在还没有提供servlet的容器实现，将来会有的，现在是跑在grizzly上面，一个高性能的NIO框架，没有之一
conf/application.conf
所有的配置都在这一个文件里面，当然，你还可以创建dev.conf ,product.conf ,test.conf这些配置文件会在启动的时候根据应用程序模式自动加载
最后
实在困的不行，也不知道你们看的懂不？大概就这样，还有好多东西没说，和后续要做的事情，具体看github吧
https://github.com/intelligentcode/ameba/issues