Ruby/Rails: 不一样的'Web'应用（续）

上一篇文章(http://www.iteye.com/topic/219826)发出之后，很多人表示对这个案例很感兴趣，要求我再深入地谈谈。应大家之邀, 我对上一篇内容进行一些补充,谈谈如何在一个传统的嵌入式领域项目中为了拥抱变化而引入web技术,以及用定制的rails框架解决非web应用问题，最后简要地谈谈一般性应用的思考。

在上一篇中,我轻描淡写地描述了由于客户对W设备赋予更多角色而导致W设备功能需求暴涨,最终选择web技术来解决问题,其实这里并非一蹴而就。


首先我们来分析一下要迎接的挑战:
(1) 增加很多复杂的操作界面(超出了W设备的现有资源能力)
(2) 功能变化快
(3) 需要日后可定制功能(二次开发)
(4) 维持低成本(意味着维持现有硬件架构不变)

和大多数人一样,我们首先想到的是客户的要求是不是不太合理呢?又要马儿跑又要马儿不吃草?但是很快发现这里有一个契机,那就是W设备是保持在线的(通过ZigBee网络),那么我们就有机会透过网络转移计算,于是一个方案马上跃上来: unix终端。

是的,古老的终端。

在许多年前,我刚迈出大学校门时参加第一项开发工作就是字符终端设备的开发,所以对终端还算熟悉。不幸的是,我也开发过服务端的程序,知道在ncurses库下开发应用并不轻松,拥抱变化?难！客户的第(2)和第(3)项需求也无法很好地得到满足。

我突然想起DHH在RailsConf 2007上的那个keynote(就是他大谈Cargo Cult的那次), 他把浏览器和IBM 3270做了有趣的对比。是的,那是个绝妙的对比,它给我留下的印象远大于Cargo Cult调侃。浏览器和终端本质上要解决的是同一个问题。由于web技术的发展取得长足的进步,服务器端进行应用开发资源也异常丰富。rails正是其中一颗冉冉升起的新星,更重要的是,服务器已经在跑rails了,就理所当然继续用rails。
在rails下开发应用那是太轻松了, 那么对付"功能快速变化"和"二次开发"就好办了。

那么,焦点又回到了W设备: 浏览器?

显然,在现有的硬件平台上上web浏览器是不可能的,如果升级硬件平台上WinCE或Embedded Linux,那么W设备的成本势必上升。况且,还有另外一些问题: 耗电问题，传输问题（ZigBee网络带宽极其有限,肥大的HTTP/HTML并不适合）; 而且W设备显示屏很小,所有功能操作都是只需要字符即可,无需fancy界面。因此,定义一套适合在ZigBee网络传输的协议和适合W设备的简易标记语言(MML)显然更为合理。

客户端问题解决了，现在焦点回到服务器端，rails可以作为非web应用么？

我对rails的内部细节不太了解，但是从外部来看，rails提供了以下主要服务：
1) MVC编程框架
2) 透过ActiveRecord与数据库打交道
3) 为HTML渲染提供服务
4) 其他如测试，数据迁移，插件，与web server的接口等等

其中份量最重的ActiveRecord部分，与web完全无关。很多便利工具例如测试，数据迁移，插件机制等等，其实与web也无多大关系。

既然rails的MVC中，M与web无关，C部分主要留给业务逻辑，而V部分对于非web领域价值不大，倘若要基于rails再建一个领域特定的MVC，工作量也就是集中在V部分了。而这个V部分，既然是领域相关，则无论采用什么方案都是一个不可避免的工作。当我们把rails的思想与习惯用法再应用到这个新的MVC上时，我们就得到了一个基于rails并且与rails神似的框架。我也来创一个buzzworld: DSF(Domain Specific Framework)，或者谦虚一点：RBDSF(Rails Based Domain Specific Framework)。

就我的案例来看，这个DSF采用的通讯不是HTTP/TCP/IP而是基于ZigBee无线网络的自定义协议，展现数据的不是HTML而是自定义的MML，然而编程模式却和rails的web应用类似。举个简单的"Hello world"程序作为例子:

contollers/main.rb:

class MainController < WSController
  controller_map_to :m
  action_maps :index => "i"
  
  def index
    @text = "Hello world"
  end
end

views/main/main_index.erb:

<%= "<P3.20CrS2E3.5>#{@text}" %>

在MainController中的controller_map_to起的作用是把自己（main）映射到一个较短的名字"m"，而action_maps则对action取短的别名，这样做主要是为了减少请求串的长度。剩下的，就和rails差不多了。
再看看view，其中<P3.20CrS2E3.5>表示在第3行20列处(P3.20)，以红色(Cr)2号字(S2)显示@text，经过3.5妙后清楚屏幕(E3.5)。当然，如果想以更好的方式描述这个MML属性，则可以定义一系列helper函数,或者来点重的，弄个DSL。
这个例子没有演示Models，因为它是直接使用rails的Models，因此使用起来没有丝毫差别。

[补充：在我的上一篇文章中，有一个功能我没有介绍，那就是模拟器。由于W设备需要在ZigBee网络中工作，对应用开发人员来说，为了开发应用而去安装整套设备比较麻烦;另外，客户想把整个系统作为产品推广，而不仅仅是自家用。这样一来，就需要有一个可以模拟W设备的环境,怎么实现？

由于W Server是用ruby写的并基于rails，因此产生了一个绝妙的解决方案：在rails应用程序的一个控制器中直接调用W Server，把W Server的输出(MML)转换成HTML;同样的，把浏览器传来的@params内容转换成W Server需要的格式，然后我们就可以用浏览器模拟W设备了。当我们把用浏览器模拟W设备这个解决方案告诉客户时，客户诺以重金，而其实我们才用了数百行Ruby代码而已:-)]

总结：
遇到需求变化时，运用恰当的技术手段有时候可以柳暗花明,特别是跨领域交叉应用，能收到意想不到的效果。web技术的长足发展，也能给其他领域带来福音。当我们把MVC的概念推广到web之外，那么这个V就可以是任意的领域特定的数据展示格式。它既可以是基于文本的，也可以是基于二进制的；既可以自定义，也可以去兼容已有的格式；如果我们仔细去分析，其实很多基于主机计算模型的应用都可以用定制的MVC框架来实现，好处是MVC能够使应用程序结构更加清晰。而基于rails来实现DSF的优势是:rails已经提供了很好的基础，加上Ruby语言的强大语法，可以以很小的代价来实现适合你的应用的DSF。

很棒!
你没有介绍自定义协议的细节。猜测客户端(W端)发过来的路由信息也需要一个routes.rb转发到controler和action上, 不需要分散做 controller_map_to :m  和  action_maps :index => "i"  这部分也许应该放到WSController  里

楼主已经不错了。估计设计到商业秘密，不能再详细了。个人觉得给出这个思路就已经很不错了。以后遇到类似问题也可以做类似处理。

其实在第一篇就已经把思路阐述的很清楚了，直接使用 rails 的框架，所做的修改只有

1. 对W设备以及ZigBee的数据传输进行一定的封装（可能需要网络硬件的改动，不过我猜测是不需要改动）
2. 定义一种新的 Markup Language （MML）
3. 对W设备于Rails之间的通信进行再次封装（W Server，可能包括部分对W设备返回数据的解析）
4. 定义基于 ERB 的新模板系统，生成 MML
5. 辅助函数（比如 controller_map, action_map, render ）

除了这些意外，其余的开发和普通的 Rails 应用无异

 

P.S. 只是我个人对这个问题的分析，不代表楼主的想法和具体实现 :)

 

这里的“controller_map_to :m”正是为了告诉routes.rb转发针对"m"的请求到"main"上，而action_maps :index => "i"也是为了转发对"i"的调用到"index"上。由于这个映射关系是应用程序要提供的，无法放在WSController。

 

你的分析基本到位：），只不过这里的W Server其实和rails并不进行直接通讯（也就是不经过rails的routes），仅仅是简单地使用了rails的设施而已。

 

第一篇中提供细节较多，这一篇主要试图从更加通用的角度去分析，因为我认为这个解决方案/解决问题的方法是可以适用于很多场合的，如果大家觉得有借鉴的地方，或者能从中获得某些启发，那么我的目的就达到了，呵呵～。

lz，我有个问题，我听说无线通讯（手机），需要保持一个长链接，不知道你的应用是否需要，如果需要，如何做到的？

貌似只是使用rails mvc中的m和一半v而已，c都是自己重写的啊。

ZigBee没有“长连接”的问题。有兴趣的话可以从这里http://www.zigbee.org/en/spec_download/zigbee_downloads.asp下一个spec来看看，免费的。

是的，C比较简单，重写成本底。M分量重，意义最大。另外rails的一些辅助设施也是捡现成的。