IoVC，一种新的编程思想

1. 概述

长久以来，在Web编程中，一直很难克服的一个问题就是：展现层与业务数据纠缠在一起，无法进行良好的解耦， 从而造成应用系统的扩展性差，维护成本高。于是，出现了所谓的MVC框架，试图以 Model-View-Control 这种非常流行的设计模式，将两者有效的隔离开来。但回顾目前主流的 Web MVC 架构，它们所做的绝大部分工作无非是：将页面中控件的值取出打包成 Java Bean；再无非就是在帮助你完成页面导航的过程中，辅助你进行页面参数的传递与分析。这样一种“简单 MVC”架构，是无法完全解决“展现层与业务数据完全解耦”这个问题的。 一旦你的需求超越了框架的能力，那么，你将面对的依然是：不得不在展现层中嵌入大量的 Script 代码，可能是Java代码片断，也可能是大量tag-lib及EL表达式的引入。

 

2. 什么是IoVC

IoVC——“Inversion of View-Control”，即“视图控制反转”，换言之：它能够把对“View（即 UI 视图）的控制力”注入到你的后台业务逻辑中。这样一来，你在编写业务逻辑的过程中，对 View 拥有足够的控制力，从而能够将展现层与业务逻辑完全的解耦。

 

举一个场景：页面中有一个文本输入框，它的值对应后台的一个JavaBean的属性。我们首先来看一下传统的编程模型：

 

页面：
<w:textField value="#{myBean.value}"/>
后台：
public class MyBean {
    private String value;
    public String getValue() {
        return value;
    }
    public void setValue(String value) {
        this.value = value;
    }
}

 

此时，假设用户需要发生变化，我们需要设置文本输入框的tooltip，并且，它的值来自于后台 JavaBean 的另一个属性，那么，程序需要做如下调整：

 

页面：
<w:textField  value="#{myBean.value}" tooltip="#{myBean.tooltip}"/>
后台：
public class MyBean {
    private String value;
    private String tooltip;
    public String getValue() {
        return value;
    }
    public void setValue(String value) {
        this.value = value;
    }    public String getTooltip() {
        return tooltip;
    }
    public void setTooltip(String tooltip) {
        this.tooltip = tooltip;
    }
}

 

我们可以观察：在传统的编程模型下，如果页面逻辑发生变化，我们首先需要修改UI展现层，加上 tooltip="#{myBean.tooltip}"　的语句，然后，再在后台Bean中设置此属性值。

那么，在IoVC编程模型下，情况又是怎样的呢？

 

页面：
<w:textField id="txt"/>
后台：
public class MyBean {
    @Bind(id="txt")
    private String value;
}

 

如果需要扩展文本编辑框的tooltip属性，只需要：

 

页面：
<w:textField id="txt"/>
后台：
public class MyBean {
    @Bind(id="txt")
    private String value;

        @Bind(id="txt" att="tooltip")
    private String tooltip;
}

 

在IoVC编程模型下，Web页面不需要发生任何变化，你只需要在后台 Java Bean 中写上这样一行属性声明即可@Bind(id="txt" att="tooltip") private String tooltip，甚至于你连传统的getter/setter都不需要。

 

换言之，在传统的编程模型下，页面美工通过网页设计工具“画”出来的页面，程序员看不懂； 而如果程序员对页面进行修改，则页面美工又无法理解； 并且，如果要更改业务逻辑，程序员需要不断的维护页面内容，最终造成页面美工与程序员无法协同工作。而在 IoVC 的编程思想下，页面美工只需要给每个组件设置一个ID，程序员在后台的业务逻辑中，便拥有对页面 UI 元素的完全控制力。Web页面在美工完成之后，程序员再也无需因为需求的变更或者逻辑的变化，而再重新维护 Web页面内容。

 

简而言之，IoVC是一种更好的MVC，是对MVC的一种高层次抽象。

 

设想一下：日后美工人员画出来的页面（只要设置了正确的ID），程序员可以拿过来直接用，并且， 如果要对页面做调整（只要不是页面元素的增加或删除），程序员可以在自己熟悉的代码中直接设置，这岂非是一种很享受的境界？

 

更多技术文章，请见：http://www.operamasks.org/

 

评论

68 楼 sxsxsx3 2008-03-27  

hax 写道

apusiczhang 写道

至于pig345兄所提到的：同一套应用逻辑（这里的逻辑二字，有些含糊，恕笔者口拙，无法详细阐述，但想必不少朋友应该可以理解），如果需要两种不同的面貌（html?xml?)，其实这在OperaMasks中是再简单不过的问题：UI是基于组件的，我们更换一下组件的RenderKit即可。

换renderkit说得轻巧，但是是有前提的。那就是你的UI组件是足够抽象，譬如是设备无关的。那就不可能在UI组件里包含具体的style。否则我就很质疑所谓换renderkit的可行性。

因为renderkit实际是开发者所不能控制也不应控制（所谓透明）的中间层，这就说明style是不应该从你的java类穿越renderkit抵达页面的，而应该和你的java类解耦。

renderkit是指组件渲染的实现吧？从jsf的生命周期来看，在invoke application之后，就是组件渲染了，这个时候renderkit根据组件树来重绘页面是不是啥都可以生成？

67 楼 sxsxsx3 2008-03-27  

看了这么多，有点糊涂了。这种东西到底怎么样听来听去也不知道所以然，姑且去down个下来试试。觉得对于一种尚未了解的新技术，先不论好与坏，能给实际应用带来价值才是有意义的。

66 楼 hax 2008-03-27  

apusiczhang 写道

至于pig345兄所提到的：同一套应用逻辑（这里的逻辑二字，有些含糊，恕笔者口拙，无法详细阐述，但想必不少朋友应该可以理解），如果需要两种不同的面貌（html?xml?)，其实这在OperaMasks中是再简单不过的问题：UI是基于组件的，我们更换一下组件的RenderKit即可。

换renderkit说得轻巧，但是是有前提的。那就是你的UI组件是足够抽象，譬如是设备无关的。那就不可能在UI组件里包含具体的style。否则我就很质疑所谓换renderkit的可行性。

因为renderkit实际是开发者所不能控制也不应控制（所谓透明）的中间层，这就说明style是不应该从你的java类穿越renderkit抵达页面的，而应该和你的java类解耦。

65 楼 hax 2008-03-27  

apusiczhang 写道

To Robbin兄：
    1) 模版语言：OperaMasks 已经在路上，那就是 Facelets。
    2) Annotation：在 OperaMasks 2.0中，已经大量运用了 Annotation。Robbin兄人在上海，套用上海的一句方言是：“Annotation不要太多哦。”
    3) JSF：我们站在JSF规范之上，取之精华，弃其糟泊。我们克服了许多JSF规范中不尽人意的地方，如对状态的维护，但同时，吸取了JSF大量的精华所在，如：组件模型、生命周期等等。但至于是否完全彻底的抛弃JSF，坦白说，我们也正在思考。

虽是跟robbin同志说的，我也来凑个热闹。

关于annotation。

我觉得annotation是个好东西是无疑的，但是我们当然也知道它所带来的耦合。为什么anno那么红，我个人觉得是原先许多解耦是无必要的，比如ORM，在多数时候把ORM规则写到单独的xml里并没有提供什么好处，因为它本来就是依赖你的Object model的，反而造成维护不便。

但是UI就大大不同。UI和app logic（更不要说domain logic）的耦合永远是麻烦的根源。

实际上，我们的问题是UI自身的logic怎么办。因为UI要越来越复杂。过去我们被迫写在jsp/taglib里，这导致一个极大的问题，就是ui logic和app logic交织到一块儿了。诚然这两者之间的界限并不是清晰的，就如同app logic和domain logic一样，有时候边界是模糊的。但是确实是存在区分。否则就不会有UI组件一说。UI组件无非是要把UI逻辑给包起来，别泄漏到app logic里。

我认为真正你要解决的问题是如何UI归UI，app归app。所以出现问题不是你对UI控制力太弱，而是你对UI控制太多。这看似矛盾，实则是深层问题的必然结果。因为UI自己搞不定，只好你想点法子越俎代庖。

关于JSF，偶只有一点题外话，取精去粗，这固然好，但是如果你们不能影响JSF的规范的发展方向，那还是白搭。总得来说，我对JSF的印象就是：它是一个续命的技术，而不是一个创新的技术。

64 楼 hax 2008-03-27  

apusiczhang 写道

pig345 写道

再具体的：你为什么不能在当用户输入某些不合法的字符给这个字段的时候，（在后台判断完成后，产生返回页面时），在这个字段上加上class='invalided_field'呢？
在css定义中完全可以在不同的界面方案（我说的皮肤）中，定义不同的.invalided_field{}，从而使用不同的颜色／外框／背景色等等。。。

多多利用web本身提供的灵活性不是更好？

有时候解决问题不要太急于看实现，退一步，抽象点会获得很多灵活性，这种思考方式对框架作者尤其重要阿。

你说的对，一定要充分利用Web本身提供的灵活性。
但现在的问题并不是强调是用style，或者styleClass，还是说把 style 或 styleClass 的内容放在页面中还是放在后台 Bean 中的问题，笔者一直想强调的是：假设style或者styleClass都已经定义好了（且不论它是定义在哪里），那么，如何根据用户的输入，来更改UI的表现。
IoVC，让你拥有了一种能够在后台Bean中影响UI表现的能力。
仅此而已。

你那意思，不是做项目，而是来玩hack的？

UI本身如脱缰之野马。我们要做的就是通过各种方式加以规约，以便驾驭。

所以你无故提供这样的功能只能是潘多拉之魔盒。

说什么怎么怎么用……那是无意义的。JSP还叫你用taglib不要用scriptlet，有人听么？况且到目前为止你举的例子没有一个有足够的正当性。

63 楼 hax 2008-03-27  

apusiczhang 写道

首先请"pig345"兄再观察一下笔者的语句：我并不认为将style放到后台Bean是最佳解决方案。
但同时，也请"pig345"兄考虑这样一个问题：（我的这个场景举的可能也有问题，但时间紧，一时半会想不到更合适的场景）
假设用户需要这样一种场景，在某个textField中，当用户输入某些不合法的字符，字体颜色变成红色，否则，字体颜色是蓝色。
并且，对这些字符是否合法的判断，需要到数据库中进行查询对比。
请问，这种场景，怎样解决最合适呢？

再回到楼主关于换肤的话题，何谓换肤？是指不影响用户业务逻辑的情况下，自由的更改应用系统的UI风格。
但上面的这个场景，它已经不是“换肤”所能解决的问题，这个场景本身就是用户的一种逻辑。

这样的假设（红字蓝字）不是太过肤浅就是有意斧凿。下次用户改规则了，改粗体斜体了，你还改你的java代码里面的bind？？？

你这个思路不过是说所有问题都拿java扛吧（让java可以控制你的ui）。我们也想用一种语言包打天下，但是这是不可能也是自寻烦恼的。

至于说所谓逻辑。这纯粹是逻辑不清。用户在提需求的时候他没有presentation/app logic/domain logic的区分是非常之正常的。但是身为设计开发者，认为对具体UI的具体改动也能属于某种逻辑，那就很有问题。对用于“和谐”的一次性项目我没意见，管你怎么做无所谓。如果用在real world应用中，我就不敢苟同。

62 楼 hax 2008-03-27  

您一举例，偶们就发笑……

这个例子反映了传统CS编程（通过bean来做界面）的遗毒。

Web的做法是这样的：

label#name:lang(zh) { width:100px; }
label#name:lang(en) { width:200px; }

表现层的东西就是表现层。

你所作的改进，或许充其量可以说是为传统做法续命。

apusiczhang 写道

我再举一个场景：
假设我们的应用系统需要支持中文和英文两种语言。诸所周知，由于中英文的差异，会导致UI的表现也会有差异。
举个简单的例子，倘若我们有一个Label，中文下，它显示："请输入姓名"，而在英文下，显示"Please input your name"
换言之，中文下，这个Label的长度为100，而英文下，它的长度要为200才能够将字符显示完全。
这种问题如何解决？
在IoVC下（确切的说是在OperaMasks 2.0下），我们可以直接在资源文件中这样定义：
#LocalStrings_zh_CN.properties
SomeBean.labelId.width=100

#LocalStrings_en_US.properties
SomeBean.labelId.width=200

然后，我们无需再做任何事情，IoVC会自动帮助我们进行lable长度的调整。

这种解决方案无疑是非常自然的，或者套用目前的流行词汇，是非常“和谐”的，而我们的维护成本也很低。

那么，传统的、常规的解决方案是怎样的？
首先，依然要定义资源文件，
然后，在页面中引入这个资源文件，
<f:loadBundle basename="messages1" var="msgs" />
最后，在Label的定义处这样写：
<label width="#{msgs.SomeBean.labelId.width}"/>

哪种方案更优雅一些呢？

61 楼 xxjhappy 2008-03-27  

对于楼主提出的IoVC+jsfc，感觉同Tapestry有点类似阿，难道真的可以让美工和程序员之间的关系变的更为松散么？还有一个问题就是jsf由sun推出后，一直感觉有气无力的，看楼主的介绍感觉这个东西和jsf还是有着联系的，不知道如何能打破目前jsf的窘境？

60 楼 apusiczhang 2008-03-27  

pig345 写道

问题是在于，即使是最强调实用、敏捷、快速开发的ROR都严格遵循着MVC的老路子，而没有反行之，应该能说明点问题吧。（ROR倒是把3层结构给抛弃了，不像j2ee还很强调多层）

你说的对。

RoR确实带给我们很多思路，很多启发，但不能因为RoR的实现方案而限制了我们的思路，IoVC也并没有反行之。

何谓MVC？
笔者以为：所谓MVC，就是要降低Model和View之间的耦合度，同时通过Controller将Model和View之间需要耦合的部分加以控制，因此，Controller的能力越强，MVC架构的质量就越高，IoVC实际上就是要最大程度地增强Controller的能力，使Model和View之间的耦合度降到最低。

和传统MVC比较，IoVC中的model和view之间的耦合度更低，仅仅通过某种映射关系将model和view之间建立关联，
没有什么form bean，action之类的东西，因此model和view可以独立维护（再次重申，我前几篇回复中那个style的例子，确实没有举好，相反，这个例子反而会给大家带来许多误解，认为IoVC就是把view塞进model），而且model和view之间可以是多对多的映射，更可以实现粗粒度的应用组件。

当然，IoVC并不仅仅只是通过几个annotation在Model和View之间建立关联那么简单，它还包含许多其它的东西，如：在IoVC中，还有一种模型事件，View的动作可以触发模型事件，而Model可以监听自己感兴趣的事件；这样做的目的，其实也是为了降低View和Model的耦合度而已。

59 楼 令狐不冲 2008-03-27  

这帖子真够热闹的，学习中～～

58 楼 plutluo 2008-03-27  

pig345 写道

注意这里的多个view不是指多个包含相似html代码的页面，这应该是模板引用（include）解决的问题（view的代码重复问题）。
如果你是真的需要多个view，比如warp一套，xml一套，html一套...，你要的功能本身就复杂了（比正常多了2倍），与其他各种实现相比，把相同的业务逻辑放到model里，而不同的展现形式放到不同的view里面，再把 根据不同的客户端返回不同view的责任 让给controller，是最省心的架构。
这个场景就是最适合用mvc来解决的场景。

如果不考虑多view其实怎么折腾都差不多，无非是代码的分割问题，或者心理问题（觉得不爽），呵呵。

plutluo 写道

pig345 写道

sxsxsx3 写道

引用

这种在后台影响UI表现的能力，还是不要有的好！

为啥呢？

我想他的后台是指model。
由于view和model的不同职责所在，不能让model管理某个特定的view的展现逻辑，这样既会造成model的过分负担（如果有多种不同的view就更麻烦了），而又把view变成了白痴（连怎么展现自己都不能作主了）。

如果对应同一个model有不同的view展示，在表现层需要根据不同的要求来构造不同的view展现么？如果说在view中增加控制展现的逻辑，那么view的复杂度就增加了不少阿。

到楼主介绍的论坛看了一下，觉得Facelets的复合组件的使用在对多个view的展示好像能避免重复的代码出现。

57 楼 pig345 2008-03-27  

问题是在于，即使是最强调实用、敏捷、快速开发的ROR都严格遵循着MVC的老路子，而没有反行之，应该能说明点问题吧。（ROR倒是把3层结构给抛弃了，不像j2ee还很强调多层）

apusiczhang 写道

其实笔者一直想强调的是：应用系统的可扩展性及可维护性，是我们的焦点所在；而MVC只是我们的一种手段，一种模式。

如果非要用Model、View、Control这三个东西来往IoVC上套的话，那么，我感觉：ManagedBean，其实更像是Control，或者是Control与Model的混合体。

至于pig345兄所提到的：同一套应用逻辑（这里的逻辑二字，有些含糊，恕笔者口拙，无法详细阐述，但想必不少朋友应该可以理解），如果需要两种不同的面貌（html?xml?)，其实这在OperaMasks中是再简单不过的问题：UI是基于组件的，我们更换一下组件的RenderKit即可。

56 楼 pig345 2008-03-27  

注意这里的多个view不是指多个包含相似html代码的页面，这应该是模板引用（include）解决的问题（view的代码重复问题）。
如果你是真的需要多个view，比如warp一套，xml一套，html一套...，你要的功能本身就复杂了（比正常多了2倍），与其他各种实现相比，把相同的业务逻辑放到model里，而不同的展现形式放到不同的view里面，再把 根据不同的客户端返回不同view的责任 让给controller，是最省心的架构。
这个场景就是最适合用mvc来解决的场景。

如果不考虑多view其实怎么折腾都差不多，无非是代码的分割问题，或者心理问题（觉得不爽），呵呵。

plutluo 写道

pig345 写道

sxsxsx3 写道

引用

这种在后台影响UI表现的能力，还是不要有的好！

为啥呢？

我想他的后台是指model。
由于view和model的不同职责所在，不能让model管理某个特定的view的展现逻辑，这样既会造成model的过分负担（如果有多种不同的view就更麻烦了），而又把view变成了白痴（连怎么展现自己都不能作主了）。

如果对应同一个model有不同的view展示，在表现层需要根据不同的要求来构造不同的view展现么？如果说在view中增加控制展现的逻辑，那么view的复杂度就增加了不少阿。

55 楼 plutluo 2008-03-27  

pig345 写道

sxsxsx3 写道

引用

这种在后台影响UI表现的能力，还是不要有的好！

为啥呢？

我想他的后台是指model。
由于view和model的不同职责所在，不能让model管理某个特定的view的展现逻辑，这样既会造成model的过分负担（如果有多种不同的view就更麻烦了），而又把view变成了白痴（连怎么展现自己都不能作主了）。

如果对应同一个model有不同的view展示，在表现层需要根据不同的要求来构造不同的view展现么？如果说在view中增加控制展现的逻辑，那么view的复杂度就增加了不少阿。

54 楼 apusiczhang 2008-03-27  

pig345 写道

apusiczhang 写道

让你拥有了一种能够在后台Bean中影响UI表现的能力。

还是忍不住再说两句。如你所说，这个是IoVC的本质上要提供的。
然而就是这个能力，其实是完全有悖于MVC的，（似乎是四人帮还是其他资料里有个例子说道这个问题），MVC原则是Model中作业务规则的判定（具体到这里就是给出某字段是否正确的boolean），而怎么表现是各个不同View自己决定的。
注意是view查询model，然后自己作决定展现成什么样子，这个正是view和model的不同职责所在。

想象一下，如果这时候要你提供一个供其他系统查询/修改的基于web的接口（典型的需要是返回xml），你怎么作？能让两个不同的view（一个html的，一个xml的）使用同一个model？

说道这里忍不住要提到ROR了，可以看看他的MVC是怎么分离的。

其实笔者一直想强调的是：应用系统的可扩展性及可维护性，是我们的焦点所在；而MVC只是我们的一种手段，一种模式。

如果非要用Model、View、Control这三个东西来往IoVC上套的话，那么，我感觉：ManagedBean，其实更像是Control，或者是Control与Model的混合体。

至于pig345兄所提到的：同一套应用逻辑（这里的逻辑二字，有些含糊，恕笔者口拙，无法详细阐述，但想必不少朋友应该可以理解），如果需要两种不同的面貌（html?xml?)，其实这在OperaMasks中是再简单不过的问题：UI是基于组件的，我们更换一下组件的RenderKit即可。

53 楼 plutluo 2008-03-27  

allenBen 写道

感觉有点像WEB-work或者struts2，直接是页面从Action里边拉数据

好像不是吧，从贴的例子中看，页面上没有el表达式阿，页面通过啥方式从后台拉数据？

52 楼 pig345 2008-03-27  

sxsxsx3 写道

引用

这种在后台影响UI表现的能力，还是不要有的好！

为啥呢？

我想他的后台是指model。
由于view和model的不同职责所在，不能让model管理某个特定的view的展现逻辑，这样既会造成model的过分负担（如果有多种不同的view就更麻烦了），而又把view变成了白痴（连怎么展现自己都不能作主了）。

51 楼 sxsxsx3 2008-03-27  

引用

这种在后台影响UI表现的能力，还是不要有的好！

为啥呢？

50 楼 qinqin050 2008-03-27  

继续关注中。。。

49 楼 pig345 2008-03-27  

apusiczhang 写道

让你拥有了一种能够在后台Bean中影响UI表现的能力。

还是忍不住再说两句。如你所说，这个是IoVC的本质上要提供的。
然而就是这个能力，其实是完全有悖于MVC的，（似乎是四人帮还是其他资料里有个例子说道这个问题），MVC原则是Model中作业务规则的判定（具体到这里就是给出某字段是否正确的boolean），而怎么表现是各个不同View自己决定的。
注意是view查询model，然后自己作决定展现成什么样子，这个正是view和model的不同职责所在。

想象一下，如果这时候要你提供一个供其他系统查询/修改的基于web的接口（典型的需要是返回xml），你怎么作？能让两个不同的view（一个html的，一个xml的）使用同一个model？

说道这里忍不住要提到ROR了，可以看看他的MVC是怎么分离的。