Java版Google App Engine试用感想
Some comments on my first GAE (Java) trial
接上一篇，发表一些自己的试用感想。
例子应用的架构及实现
Architecture & Implementation of the Previous Example
先看一下自己开发了一个什么样的例子。用图说明。
看源代码，me.evis.gae.guestbook、me.evis.gae.guestbook.client和me.evis.gae.guestbook.sever三个包就是为了形成GWT的表现层和逻辑层。而me.evis.gae.guestbook.bo及其子包是为了包装GAE的数据存储服务形成数据层。
就开发过程而言，在装有Google插件的Eclipse上添加新GAE项目时，插件会代为准备好GAE相关的配置和jar包，同时也有GWT的。而创建新模块时，就纯粹是与GWT有关的事情了。在我看来Google为GWT提供的最佳实践是：
- 在前端弱化HTML的作用，而由后端位于client包里的入口类（Entry Point Class）编写用户界面及相关交互，在运行时Java的入口类会生成Javascript返回给客户端浏览器；
- 由入口类来调用同一包内的各种服务接口，并处理返回值；
- 对于client包中服务接口的实现，都放在server包中。
我之所以加入了bo包及其子包，主要还是是为了能更清楚地了解GWT与GAE之间的关系。由Comment DTO/DAO去以JDO方式去调用GAE的数据存储服务，然后再让上边的Comment服务的实现去调用Comment DTO/DAO而不是直接去调GAE的东西。
同时，这样的分离也给了我做单元测试的机会。我为bo包加入了test的子包。JUnit 3的测试用例直接写会出App ID之类的错误，原因是GAE的服务都是云计算，本地调用需要构建一个相应的测试环境，详见Google的官方文档或者是例子应用的源代码。
关于GWT
Comments about GWT
用Java来代替Javascript，有点像写CS的感觉，不过调用服务器端的方法或者使用服务器端的变量都很方便。这种做法确实掩盖了BS和Javascript的复杂性，也有效利用了Java编译所需的严谨性。但是我认为其缺点也是显而易见的：
- 开发调试用户界面及交互要改Java类，就意味着重新编译，一般也会要求重启服务器，相对来说调试成本较高；
- 用户界面开发变得不太直观，难以分工。如果所有界面都是Java写出来的，那页面设计师和交互工程师只能轮流给Java程序员端咖啡了。个人觉得如果用GWT，各种页面元素应该还是在HTML上布局好，然后用Java去捕捉那些元素，比如按钮或者区域之类的。
GAE最核心的东西肯定还是数据存储、邮件等这些云计算服务，我想如果有更适合的选择的话，还是没有必要在GWT上投入太多的关注。
关于GAE
Comments about GAE
截止到发文时也只有尝试过数据存储服务而已。关于数据存储服务，Google公布了JDO和JPA两种基于标准的接口。这些现代的数据操作方式大大简化了数据相关的开发，至少不用去数据库里建表了。但GAE是按API调用次数、数据容量、传输大小等因素综合计费的，所以开发时也必须要注意多方面的调优，个人预测Appspot上也许会有不少程序会因为API调用次数和CPU占用时间两项而额外付费。
关于Google的Eclipse插件
Comments about Google Plug-in for Eclipse
- 装完插件就不要挪动Eclipse了，不然要改好几个配置文件；
- GWT的Java Editor有时会有些bug导致无法进行语法加亮；
- GAE的插件方面有些薄弱。除了新工程和调试用的Jetty服务器外好像没看到针对Google各种云计算服务的更细节的功能。
结语
Conclusion
很兴奋，很有用。有机会也要试试其他的服务，有时间可以给自己写个实用些的程序。
缩写
Abbreviations
- GAE: Google App Engine
- GWT: Google Web Toolkit
- JDO: Java Data Objects
- DTO: Data Transfer Object
- DAO: Data Access Object
- CS: Client-server
- BS: Browser-server