壹维思_EVIS

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了，不然要改好几个配置文件； [...]