上一篇文章([url]http://www.iteye.com/topic/219826[/url])发出之后，很多人表示对这个案例很感兴趣，要求我再深入地谈谈。应大家之邀, 我对上一篇内容进行一些补充,谈谈如何在一个传统的嵌入式领域项目中为了拥抱变化而引入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调侃。[b]浏览器和终端本质上要解决的是同一个问题[/b]。由于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:
views/main/main_index.erb:
在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，因此使用起来没有丝毫差别。
[b][[/b]补充：在我的上一篇文章中，有一个功能我没有介绍，那就是模拟器。由于W设备需要在ZigBee网络中工作，对应用开发人员来说，为了开发应用而去安装整套设备比较麻烦;另外，客户想把整个系统作为产品推广，而不仅仅是自家用。这样一来，就需要有一个可以模拟W设备的环境,怎么实现？
由于W Server是用ruby写的并基于rails，因此产生了一个绝妙的解决方案：在rails应用程序的一个控制器中直接调用W Server，把W Server的输出(MML)转换成HTML;同样的，把浏览器传来的@params内容转换成W Server需要的格式，然后我们就可以用浏览器模拟W设备了。当我们把用浏览器模拟W设备这个解决方案告诉客户时，客户诺以重金，而其实我们才用了数百行Ruby代码而已:-)[b]][/b]
总结：
遇到需求变化时，运用恰当的技术手段有时候可以柳暗花明,特别是跨领域交叉应用，能收到意想不到的效果。[b]web技术的长足发展，也能给其他领域带来福音[/b]。当我们把MVC的概念推广到web之外，那么这个V就可以是任意的领域特定的数据展示格式。它既可以是基于文本的，也可以是基于二进制的；既可以自定义，也可以去兼容已有的格式；如果我们仔细去分析，其实很多基于主机计算模型的应用都可以用定制的MVC框架来实现，好处是MVC能够使应用程序结构更加清晰。而基于rails来实现DSF的优势是:rails已经提供了很好的基础，加上Ruby语言的强大语法，可以[b]以很小的代价来实现适合你的应用的DSF[/b]。
在上一篇中,我轻描淡写地描述了由于客户对W设备赋予更多角色而导致W设备功能需求暴涨,最终选择web技术来解决问题,其实这里并非一蹴而就。
首先我们来分析一下要迎接的挑战:
(1) 增加很多复杂的操作界面(超出了W设备的现有资源能力)
(2) 功能变化快
(3) 需要日后可定制功能(二次开发)
(4) 维持低成本(意味着维持现有硬件架构不变)
和大多数人一样,我们首先想到的是客户的要求是不是不太合理呢?又要马儿跑又要马儿不吃草?但是很快发现这里有一个契机,那就是W设备是保持在线的(通过ZigBee网络),那么我们就有机会透过网络转移计算,于是一个方案马上跃上来: unix终端。
是的,古老的终端。
在许多年前,我刚迈出大学校门时参加第一项开发工作就是字符终端设备的开发,所以对终端还算熟悉。不幸的是,我也开发过服务端的程序,知道在ncurses库下开发应用并不轻松,拥抱变化?难！客户的第(2)和第(3)项需求也无法很好地得到满足。
我突然想起DHH在RailsConf 2007上的那个keynote(就是他大谈Cargo Cult的那次), 他把浏览器和IBM 3270做了有趣的对比。是的,那是个绝妙的对比,它给我留下的印象远大于Cargo Cult调侃。[b]浏览器和终端本质上要解决的是同一个问题[/b]。由于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，因此使用起来没有丝毫差别。
[b][[/b]补充：在我的上一篇文章中，有一个功能我没有介绍，那就是模拟器。由于W设备需要在ZigBee网络中工作，对应用开发人员来说，为了开发应用而去安装整套设备比较麻烦;另外，客户想把整个系统作为产品推广，而不仅仅是自家用。这样一来，就需要有一个可以模拟W设备的环境,怎么实现？
由于W Server是用ruby写的并基于rails，因此产生了一个绝妙的解决方案：在rails应用程序的一个控制器中直接调用W Server，把W Server的输出(MML)转换成HTML;同样的，把浏览器传来的@params内容转换成W Server需要的格式，然后我们就可以用浏览器模拟W设备了。当我们把用浏览器模拟W设备这个解决方案告诉客户时，客户诺以重金，而其实我们才用了数百行Ruby代码而已:-)[b]][/b]
总结：
遇到需求变化时，运用恰当的技术手段有时候可以柳暗花明,特别是跨领域交叉应用，能收到意想不到的效果。[b]web技术的长足发展，也能给其他领域带来福音[/b]。当我们把MVC的概念推广到web之外，那么这个V就可以是任意的领域特定的数据展示格式。它既可以是基于文本的，也可以是基于二进制的；既可以自定义，也可以去兼容已有的格式；如果我们仔细去分析，其实很多基于主机计算模型的应用都可以用定制的MVC框架来实现，好处是MVC能够使应用程序结构更加清晰。而基于rails来实现DSF的优势是:rails已经提供了很好的基础，加上Ruby语言的强大语法，可以[b]以很小的代价来实现适合你的应用的DSF[/b]。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
