Some comments on my first GAE (Java) trial

Java版Google App Engine试用感想
Some comments on my first GAE (Java) trial

上一篇,发表一些自己的试用感想。

例子应用的架构及实现
Architecture & Implementation of the Previous Example

先看一下自己开发了一个什么样的例子。用图说明。

me.evis.gae.guestbook_architecture

看源代码,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