IoVC，一种新的编程思想

这篇文章从一开始就没有说清楚，而且所举的例子也不恰当。IoVC并不是要将model绑定到view中，那些annotation只不过是表象。IoVC所做的是将一个活动的、易变的、复杂的交互逻辑用不同的视图表现出来，model和view都是对同一个事物的不同表述，就象在工程制图中用三个二维视图描述一个三维实体一样。Model关心的是业务逻辑，而view关心的是展现逻辑，但他们都是为应用逻辑服务的，因此是对应用逻辑的投影，当应用逻辑发生变化，它的两个投影也将同时发生变化。在传统的Web MVC中model和view之间存在一些辅助线，以帮助反映对逻辑实体的联动变化，IoVC去掉了这些辅助线，使整个架构更加简洁。

严格来说，IoVC并不是一个MVC架构，只是借用了MVC架构中的一些概念。

“坦白说用google快十年，就没发现它的展示有怎么变过，MSN web邮箱也是用了这么久只变过一次。”

不行了，为什么你们举的例子都那么令人无力啊！

“展示层发生根本性结构变化的次数，屈指可数”——请问什么是根本性结构变化？非根本性结构变化又是什么？次数是不是一手数得过来？

前面已经说了，这里谈view/model，只是mvc里的model和view。不要扯到几层service之后的那些model（比如db model？）那里去吧！

“只要业务层一变，或者更具体点，只要业务层到展示层的接口一变，展示层就必然要跟着变。”

业务层变化=>业务层到展示层的接口变化，这有必然的因果关系么？如果真的必然变化，那说明什么问题？如果展示层本身真的没有变化的要求，难道不能维持接口不变吗？facade、adapter、proxy、bridge等等都吃干饭的啊？

“还会有一大批程序员从小就认为展示层必然比业务层易变呢？”

这是因为，展示层确实是比业务层易变。企业应用系统的本质就是如此。你跑来说我做UI库的，我的UI库要适应不同的数据源，所以是展示层稳定，业务层易变。那叫狡辩。因为对于做UI库的来说，UI库就相当于企业应用的业务层了。

任何一个企业应用的目标都是稳定的业务层。做得到做不到那是另外一回事情。

“如果只在web展示的范围内考虑多个展示，那么如何让模型的变动尽可能不影响到展示，则更为重要。因为如果模型变动必然会影响到展示，一个模型变动会导致N个展示跟着变。”

所以我不知道你这个话是站在什么立场在说，如果你是站在Web框架开发者的角度，那么拜托，这个视角是不同的好不好。

“不要在计算加法的函数里写printf，因为要分离展示与逻辑。”

拜托，这是强调分离展示和逻辑么？这本来就是一般的职责分离而已。

“那为什么他不能说如果明天我们要把数字加法改为字符加法，只改算法函数就可以了？”

为什么不可以？当然可以！只要你的需求是需要做这种抽象的话。

“是不会刻意强调“如果业务层变动比展现层变动要快”的场景的，道理很简单，因为此题无解。”

请给出“业务层变动比展现层变动快”的例子。

“JSF的嵌入EL表达式，JSP的<%! %>，libtag， struct的url pattern。”

我说的不是这种东西。我说的是组件与数据源绑定。例如<select source="mylist.xml">这类的。

“IoVC而在模型里绑展示层，绑什么？绑id”
“模型代码事实上不管另一端是什么组件，展示组件也不管另一端是个什么接口签名”

你说的这个跟我直接在网页里内嵌${xxx}有什么区别？
我看下来貌似就是自动反射（或者通过annotation）java类的property，然后populate成一堆html属性而已。请问，这比自定义Taglib优势在哪里？

不要告诉我优势就是：没有限制。

“IoVC只是提供了在某些特殊场景下可以这样做的机会。这正如c语言不会禁止你写段代码低级格式化系统硬盘，但并不代表它推荐你没事就格式化。通过这样做，IoVC弱化了模型与展示之间的单向耦合，令它们可以分别独立演化。 ”

这种说辞很无力。什么叫框架。框架就是要给出规约，要强制一些规则。而IoVC却是堂而皇之的允许java类直接去设定html上的属性，我猜不久就可以看到java类里面出现许多javascript的onxxx的handler。

“通过这样做，IoVC弱化了模型与展示之间的单向耦合”

真没看出来哪里弱化耦合了。我看到的是危险的侵入性，打破分层，可能被用来hack。如果你说IoVC可以起到一点代码生成的作用，倒还好说。

关于耦合还有一点，你要绑定id。我问，html上id变了咋办呢？
你不要回答我说id是不准变的。

“IoVC对这个问题的解决方案是，展示层设计人员只需要在页面上放一个button组件，或者一个link组件，或者一个TreeNode，随便什么东西，并指定id。他需要与模型程序员约定：“我会放一个id叫submit的东西……是啥你别管……来提交表单，用一个id叫birthday的东西来显示生日，你自己看着办。””

你说的无非是分离表现层中的data instance、submission和ui control。想法是好的，但是认为让IoVC根据id来填充数据就能解耦就本末倒置了。这里IoVC是可有可无的（如果不是起反作用的话）。关键是你有好的表现层架构，跟业务层根本无关。XForms就是很好的例证。

我说说我理想中的企业应用的MVC的形式。

企业应用的特点就是form多。绝大多数交互场景都可以归纳为填form，submission，然后得到report。

当然我有些过度简化（我们有很多周边需求，比如搜索、集成Email、sms诸如此类），另外总是还有导航和portal，这可以视作一个单独的问题。去掉这些，大多数企业应用中的各种业务管理的功能所需的web交互差不多就是这样的。

C这里需要控制所有这些form和submission（action）的flow。这里要解决无状态的问题。

所以比较理想化的分析就是这样：

用户请求一个特定任务，则C先找到该任务的flow，然后找到flow中与当前状态所对应的form（view）。view内会通过某种机制（通常就是URI）绑定许多数据实例。注意这里不应由C直接去填充数据给UI组件，应该由view声明其所需的数据源，并由view自己把从数据源得到的数据实例和view中的UI组件绑定起来。这样才是UI归UI，app归app。这里是松耦合的，M和C都不知道V中的UI细节。

其他部分与现在的web MVC基本相同。比如当V提交了数据到C时（与现在已有的方式一样，这里的action分派由submission指定，但C也可以进一步分派），C执行app logic，处理传入的数据，如调用service，更新model，选择下一个view等等。

在这样的模型里，绑定是发生在UI组件和model的instance之间的，通过基于某种表达式语言灵活的绑定（你也可以坚持只用id绑定，但是显然这是作茧自缚），我们就解耦了ui和model。而且UI可以是抽象UI，即我们可以进一步解耦UI模型和UI的具体形式。这里需要强调一点，解耦程度有多高，关键不在于你用id绑定还是用el（因为model你是可以自行规约简化的），而是取决于UI组件的能力。UI组件对于model的假设和限制就越小，与model的耦合程度自然就越低。这就是我为什么说V越强大MVC越强大。