IoVC，一种新的编程思想

看sun的jsf介绍，不是说jsf其中一个亮点就是事件驱动么？类似swing的。

哇，hax兄对技术的热情真是令人佩服。我昨晚2点写的贴，你是4点钟回的贴。。。技术固然重要，也要注意休息喔。

老实说我对这样把贴子拆开来逐句反驳的文体不是太感冒，一来容易断章取义，只注意句子上的不足，而忽略了通篇的重点。二来容易陷入为反驳而反驳的误区，如果一篇文字，只是为了反驳对方，而没有提出自己的观点，是没有什么实质贡献的。有这个闲情不如去多写几行代码了。。。

因此，我想只就你贴子中一些真正涉及到技术的地方展开一下我的看法。对于“为什么例子这么无力”这些见仁见智的东西，就不执着了。读者自然会判断。

关于“前面已经说了，这里谈view/model，只是mvc里的model和view。不要扯到几层service之后的那些model（比如db model？）那里去吧！”（请原谅我也逐句引用，因为原贴就不连贯。。。） 这里我觉得有两个误区，首先我在贴子中说了，IoVC是试图解决一些MVC多年来没有解决的问题。如果一开始就把view/model局限在传统MVC的范围内，传统MVC制定的条条框框看成是至高无上，不容置疑的。也许语气有点重，但我觉得跟下面的情形的确有点相似：很久以前，有只青蛙，觉得天空是个烧饼大的圆圈。那么在他自愿跳出框框之前，是无法去讨论海阔天空的。第二，你引的那一句我所指的结构性变化只在界面，完全没有涉及到n层之后的model。如果不清楚界面的“内容变动”与“结构变动”之间的差别，请参考CMS(内容管理系统)和用户个性化定制的有关资料。

“业务层变化=>业务层到展示层的接口变化，这有必然的因果关系么？如果真的必然变化，那说明什么问题？如果展示层本身真的没有变化的要求，难道不能维持接口不变吗？facade、adapter、proxy、bridge等等都吃干饭的啊？”  这个“难道不能维持啥啥不变吗？”是个自从有软件开发行业以来人人都在问的问题，用瀑布生命周期开发时，人们在问“难道不能维持需求文档不变吗”。做系统整合时，人们在问“难道不能维持遗留系统不变吗” 答案是，当然可以，只是需要付出代价。facade、adapter、proxy、bridge都不是吃干饭的，但如果作为应用设计者，仅仅为了维持需求改变时业务接口不变而去关心这一摊东西，跟业务逻辑有关吗？跟界面设计有关吗？能在交付时跟客户说“我的项目虽然晚了半年，但我在自主开发的代码中用了facade、adapter、proxy、bridge等等模式，保证了模型层接口的稳定性”吗？

“这是因为，展示层确实是比业务层易变。企业应用系统的本质就是如此。”这个东西就不想再展开了，简单提醒一下，你的观点是基于“展示层必定比业务层易变，而且如果使用IoVC，展示层的变动必然传递到模型层”，两者缺一都不足支持你的观点。现在只说前半句，就算我退一步，承认有60%项目展示层比较易变，那么我还有40%的市场。而你则在试图下结论，所有应用的展示层必然比业务层易变，并由此引出后续的论点。。我不知道这有何统计根据或者理论根据。另外我也不知道“本质就是如此”这个定论怎么下的，当年老马为了说明资本主义的本质是剥削剩余价值，可是写了洋洋洒洒一大部《资本论》的。怎么这里一句话就给企业应用的本质定性了。而且我也没说过什么UI，数据源之类的，如果有人说了，那的确是在狡辩，这点我们观点是一致的。

“所以我不知道你这个话是站在什么立场在说，如果你是站在Web框架开发者的角度，那么拜托，这个视角是不同的好不好。” 还是说明了锤子和钉子的问题，view的多样性（一个模型带着多个view）的需求，带来的view与model的分离，产生了希望在model变动时如果不必要就不要影响view的需求，这是整个系统的客观需求，不会以视角为转移的，不会说我拿着UI的锤子，我看到的就都是UI的问题。我强调本帖只针对web，是因为JSF（或者ruby on rails）本来就是个针对web的东西，那么它本身能应付的，就只是web展示。如果考虑其他形式的展示，则必须要考虑web框架以外的东西。那就不在本帖的主题上了。

“为什么不可以？当然可以！只要你的需求是需要做这种抽象的话。"   不知道什么年代起“做抽象”居然变成了需求。你意思是希望客户跟你说，系统的生日字段可能会在三年后能做成多国语言，也可能需要用一个由1990年1月1日起的微秒数来显示，也可能需要做个加密算法，不过也未必一定会这样做噢，现在我只需要一个八位字符能够看出年月日就行了。听完后你就在大展拳脚在生日字段上搞出个抽象层来显示八位字符。看上去不像在做应用，倒像在写框架了。即使是，那么AOM，退一步来说，JSF早帮你把框架做好了。

”请给出“业务层变动比展现层变动快”的例子。“ —— 请给出展示层*必然*比业务层变动快的*统计数据*

”我说的不是这种东西。我说的是组件与数据源绑定。例如<select source="mylist.xml">这类的。" 不好意思，我所说的那些并没有考虑这种状况，这样不经业务层直接在UI绑数据源的做法自从foxpro，vb6就有了，不是说它不好，损誉参半吧，但用在web客户端中好象有点难度，直接绑上去了叫我的控制逻辑和业务放哪里？所以直接忽略了。而且就算考虑了，也不影响原文的论述，道理是一样的。如果你说的组件绑数据源还有什么玄机，请稍微展开说一下。

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

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

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

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

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

这几段是说框架限制的，合起来说吧，很是不习惯逐段割裂的文体。。。如果我告诉你，对了，就是没有限制，你在这里可以可以做任何事，而且很方便。有什么问题？你会说，没有限制，以后变动会很麻烦。但如果我能做到以后变动都很方便呢？当然我不是说IoVC就要做成一个万能的神，但我也没听过有谁会因为“没有限制”去排斥一个框架的，只会因为一个框架为了达到“方便”而引入的诸多限制（包括IoVC也必然有类似的限制）或者转移了的工作量而颇有微词。至于说“什么叫框架。框架就是要给出规约，要强制一些规则。” 这个我看就有点强迫症的迹象了，框架给出规则制约，是因为它给你提供方便的代价。没听过有人仅仅是为了给自己的项目加上规则和限制（注意是开发规则，而不是业务或安全规则）而去引入一个框架的。也许你想说的是编程模型，例如MVC，那么它本来就是个虚的东西，只是告诉你应该这么这么做，否则那么做会如何如何。跟一个具体的框架的所允许的能力根本没有可比性也没有冲突，我在原贴中说过，AOM允许你从bean改变展示，但没有任何人会推荐你这样做，也就是说，AOM也有其应该遵守的编程模型，反其道而行并不一定讨好，但在某些特殊场景，它提供了让你这样做的选择权利。所以我不太热中逐句反驳这种文体，它让人只在意眼前的钉子，而忽略了其他的关键。还有一个明显例子就是“你说的这个跟我直接在网页里内嵌${xxx}有什么区别”，原贴已经专门用一段文字说明了这个跟你直接在网页里内嵌${xxx}有什么区别了，在此就不重复。

关于id，首先我想问下，没事为什么要去变id? 客户会关心id吗？业务逻辑会牵涉到页面id吗？id本来就是个三不管的东西，这种既简单，又跟什么都不耦合的东西，用来作为粘合剂是最合适不过的了。另外如果页面涉及了css和javascript，有谁会有心情没事改变作为DOM标识的id来玩？但如果你说一定要跟我较真，页面里就是有id要不停的变，那么关于这个元素的动态内容，就只好请你老老实实在页面里写EL了。重申一下，框架是为了给人提供方便而存在的，作为代价，你必须要符合它的一些规则。差别只是在于，这个规则是否强加于你，如果你有一天真的需要打破规则，框架是否允许你放弃等量的方便，去换取自由，而没有给你添加任何麻烦？

如果一定要套上MVC来理解IoVC（或者说理解JSF），我觉得应该是这样的，View还是View，Model还是Model，Controller则是由页面Bean和UI组件模型类共同构成的。那么IoVC事实上是把代码中定义绑定的位置与定义行为的位置放到了Controller中。（楼上许多误区是把JSF框架看成controller，而把页面bean和UI组件类看成不伦不类的模型。这就等于把struct框架看成controller，把用户定义的action类看成模型一样别扭）

这与MVC是不矛盾的，特别地，与hax兄在楼上多次提起的smalltalk形式的MVC，有着异曲同弓之妙。MVC的原本定义，是在展示层极其单薄的情况下，所有行为（包括最初接受键盘输入这种行为）都放在controller层，然后由它去调用展示逻辑进行展示。也就是说，view只管自己（其实没什么管可言，它里面没有任何实质逻辑，只负责把自己画出来），model也只管自己，controller两边都管。但发展到web编程，这样的MVC模式是很难组织起来的，因为controller部署在服务器端，不可能直接接触到行为的发起者（例如接收键盘输入），那么必然导致了view层需要负担起调用controller的任务，形成了View同时依赖于Model与Controller的现状。这也就造成了人们认为Model相对稳定，View必然不稳定的错觉，原因很简单，Model改变时View和Controller要变，Controller改变时View要变，View改变时就不用说了。那么IoVC做的其实是，把View对Controller的依赖还原到Controller对View的依赖（而且是通过id来绑定的非常弱的依赖），而View只关心自己的展示。

至于事件，JSF本来就是基于事件的，而且AOM对JSF的标准事件机制进行了增强。

顺带一提，马大叔在06年好象试图出一本EAA续集，但不知道后来为啥不了了之了，现在马大叔好象在潜心搞领域特定语言了。但他当时的文稿还挂在网上，其中有几篇对MVC的前世今生作了通俗易懂的介绍（马大叔的一贯风格），有兴趣的朋友可以去看看：

项目主页：《Development of Further Patterns of Enterprise Application Architecture》 http://martinfowler.com/eaaDev/

如何组织展示逻辑：http://martinfowler.com/eaaDev/OrganizingPresentations.html

GUI架构（此文对MVC进行了详述）：http://martinfowler.com/eaaDev/uiArchs.html

.net 的webform 不就是这么操作嘛

我今天又把AOM的那几篇讲IoVC的文章看了一遍。我的判断没有改变，IoVC的出发点是好的，但是设计思路有问题。

下面简单的说一下。

http://www.operamasks.org/articles/iovc/html_single 这篇文章（也就是顶楼）我就不说了，因为袁老大说这个文章举例不妥。而且前面几位也一再强调给你刀不是鼓励你杀人，所以我就不追打了。

所以我来分析http://www.operamasks.org/articles/helloduck-iovc/html_single 这个。

在这个例子中，view中的差异在哪里？其实就是el被换成了id。

java类的差异在哪里？
这个java类原来包含了data和action。其中result是依赖其他数据状态的。
而AOM改成了java类的field到markup的binding。此外result被改成了基于事件填充数据。

而这两个改变都是有问题的。

第一个el换成id。AOM的出发点是避免页面中嵌入所谓“代码”。想法虽好，但是用力用错了地方。如果说el会被滥用，那IoVC更会被滥用。在这里不应该执行双重标准。

如果说希望el不要骚扰金贵的美工同志。这我完全可以理解。但是，请注意，就算你用id，你至少有一个耦合点。那么id表示什么？其实就表示一个绑定约定。这就是我前面问id的原因，可惜前面的同志说了一大堆id不用变的理由（（况且就站不住脚，请问问做前端的同志为什么要改id吧），看来完全不领会我为什么提这个问题。

如果理解了绑定约定的问题，就知道要解决这个问题根本无需引入什么IoVC，你只需要定义一个bind到el的映射就好了。这个映射可以写在view中，隔离在一个单独的tag中，也可以跟view独立开来，放在一个model中，注意这个model是该view所专属的model（尽管理论上可以复用），而与mvc里的那个model有所不同。view的model格式可以是xml或其他某种自定义格式的，用java也成，但是我认为没有必要。例如可以随手设计这样的标签：

<html
xmlns:v="http://example.hax.iteye.com/mvc/view"
xmlns:ui="http://example.hax.iteye.com/mvc/ui-controls">
<head>
<v:model>
<v:instance id="user" type="com.javaeye.hax.example.UserBean"/>
<v:bind id="first-name" el="${user.firstName}"/>
<v:bind id="last-name" el="${user.lastName}"/>
...
</v:model>
</head>
<body>
...
<ui:input>
  <ui:label>First name</ui:label>
  <ui:value bind="#first-name"/>
</ui:input>
<ui:input>
  <ui:label>Last name</ui:label>
  <ui:value bind="#last-name"/>
</ui:input>
...
</body>
</html>

其中<v:model/>部分也可以发挥所谓“配置优于约定”，如果view是*.html那就放到*.model文件中。

从这个角度说，IoVC下的java类其实是用java写的，进一步退化的model文件。但是它缺乏了像我这里的model文件那样明确的规约！我强调说框架的价值就在规约，有人不以为然，那我也没办法，各位请自行体会好了。

退一步，我们不考虑因缺乏规约而导致的问题，我们就看等价于退化的用于view的model的AOM中的java类。

我们注意到el被干掉了，你只有平面的field，而失去了灵活的el的层次性。这样扁平的java类真是连json都不如，何况xml？本来如果你聪明点儿，允许get/set方法，那还能恢复等同于el的能力，现在只能变成干巴巴的，要稍微复杂点的（比如result那个）就只好搞成beforeRender之前去赋值一下——自找麻烦。

下面顺便说说其他一些问题。

Apusic Studio的支持，乍看之下貌似是类似ASP.NET的code behind，本身没啥好说的。但是各位看官可以注意到了，这实际上告诉我们一个信号，即AOM实际是把绑定事件的模式套用到了绑定数据上！

下面我们再看http://www.operamasks.org/articles/magic-1/html_single

对于所谓配置优于约定，我先不予置评。但是明显如果按照这个理念，连annotation都不应该要。field就是数据bind，method就是action。但是诸位，不要以为我是在开玩笑，我是说真的。

再看AOM的模型事件：http://www.operamasks.org/articles/magic-4/html_single

他最后一句话是“笔者以为：事件是一把双刃剑，运用得好，那么，能够大大增强程序的灵活性及可扩展性； 但如果滥用事件，则只会让你的程序难以跟踪，难以理解。”

这个其实就心虚了，因为他文中所举的例子其实在真实应用中肯定会用集中的规则触发机制来做，而绝不会分散在各个bean里写什么事件。姑且认为又是举例无力。

AOM的同志们，难道你们不能加把劲，举个好点的例子吗？还是说举来举去就是这样了呢？

既然hax兄已经提出了要不吝赐教，我想是却之不恭了。那么请问做前端的hax同志，可不可以具体说说id为什么一定要变呢？弱弱的说，的确不太领会你为什么要提这个问题。。。

耦合点肯定是会有的，正如面向对象思想一直强调将判断结构转化为多态结构，但多态能不能彻底消除判断？不可能，它只能将判断结构前移到创建期。那么你能说多态没有用吗？问题的重点不在于有无，而在于位置与形式。IoVC与传统JSF的分别，就在于让程序员在java中管理耦合点id，还是由美工在页面去管理el。至于两者有什么区别，不想重复了，在第一条回贴里已经说过。如果考虑到一model带多view的情况，还多了个把耦合点集中起来的好处。

hax兄一直对AOM的同志举的例子很不满意，自己随手举了个例子，却真的很随手。想问下这样在同一个view里无端的多出一个间接绑定，仅仅是把el堆到一起，有什么实际意义呢。难道同一个文件头部和正文由不同人去编写？cvs里的冲突警告可不是用来看着好玩的。。。也许这里也只是举了个不恰当的例子，在真实应用中，你会把例子中model的定义部分分开，正如你所说“放在一个model中，注意这个model是该view所专属的model（尽管理论上可以复用），而与mvc里的那个model有所不同。view的model格式可以是xml或其他某种自定义格式的，用java也成”，欢迎你加入IoVC的大家庭，这正是IoVC在做的事。唯一不同的是，IoVC的绑定使用了你认为一定会变的id，而你的例子使用了一个红色的bind属性，这个实现细节我看来是无伤大雅的，只要你说明了为何id一定会变，有理有据的话，我想AOM的开发人员可以接受改用另外一个随便什么名称的属性来作为耦合点，这应该是举手之劳。

至于为什么IoVC直接在java bean中需要绑定的地方打标注，能在模型端享受强类型检查的做法是退化，你的model文件要写个无编译期检查的接口签名还要写个id的做法是进化，没想通，希望能展开论述一下。也没看出明确规约了什么。。。规约了美工必须手工核对签名拼写吗？

“本来如果你聪明点儿，允许get/set方法，那还能恢复等同于el的能力”，据我所知，IoVC是可以绑getter/setter的，句中的“本来如果”可以删掉了。另外因为这句话我可有两句要对hax兄说了，首先看来hax兄确实是忙于发贴，没闲工夫去下载个AOM试用一下。以至于看到例子里没有绑getter，又用了@BeforeRender来对result赋值，就断定IoVC只能绑field，这老实说可不是好的治学态度喔。第二hax兄看待例子的态度，好象与一般人大相径庭呀，这也就难怪AOM的同志们举不出令你满意的例子呀。一般人写文章，是以文字说理，辅以简单例子说明，有时为了配合文字，例子可能会故意走点弯路来展示特性；hax兄看文章，是忽略大段文字，只看某些句子，然后根据例子去发挥天马行空的想象……我明明在第一条回贴里说过：“一个组件id，可以帮在简单的对象域上，也可以绑在public String getPersonName()上。”，看来又是被直接忽略了。但我也觉得目前AOM的示例的确比较单薄，希望开发团队能在AOM2.0正式版发布后，能放出一些足够复杂，模拟真实场景的事例。

文中的顺便一提部分，我觉得挺好，提出了一些实现上的问题。建议AOM团队有则改之无则加勉。但其中一些细节还比较模糊，希望hax兄能展开探讨一下：

关于“AOM实际是把绑定事件的模式套用到了绑定数据上”，这句话老实说我没理解，因为对ASP.NET不熟，就算真是这样，会导致什么问题吗？从这句话后面的叹号来看，似乎是有点问题的。能不能具体说说绑定事件的模式和绑定数据的模式有什么差别，为什么套用会有问题呢？

hax兄对于增加约定规则，减少annotation的建议，我觉得挺好，例如可以考虑参考webservice的@WebMethod标注的做法，让@Bind可以打在类上，打了@Bind的类，如果内部没有使用任何field级的@Bind标注，则默认所有域是绑定域。请AOM团队考虑一下。但说到“不应该要annotation”，我觉得就有点冒失了，如果任何东西都约定默认绑定，那么难道我要配置时，要把所有不绑定的东西都打个@NotBind标注？或者hax兄事实上是说有更好的判别策略？愿闻其详。

关于例子和引文笔者的最后那句话，只是说出了基于Observer模式的事件机制的一个共性。这里可以引用马大叔的一段话来说明：“The great strength, and weakness, of observer is that control passes from the subject to the observer implicitly. You can't tell by reading code that an observer is going to fire, the only way you can see what's happening is to use a debugger. As a result of a complex chain of observers can be a nightmare to figure out, change, or debug as actions trigger other actions with little indication why. ”（ http://martinfowler.com/eaaDev/OrganizingPresentations.html ）。我觉得对于初学者，是句温馨提示。对于如hax兄般的高手，可能就是既没错但也没很多新意。但不知道跟心虚有什么关系。产品特性介绍文章中的例子，是用来辅助文字的，不是用来代替文字的，也不是用来教你在真实应用中如何选择解决方案的。当然，如果能举出一个真实场景下的简单例子自然最好，但对于事件这种只有在复杂场景下才显出其优势的东西，不举出个四五页的例子就是心虚了吗？其实也未必。。。但不管怎样，至少说明目前大家对例子的需求，还是希望AOM开发团队能发布更多高质素的示例。

给正下名，包装一个概念也蛮好的，哈哈

1. 偶是没用过AOM，因为我对JSF根本就不感冒。而且我没有必要也没有义务先要用过AOM再去批评它。如果说我看了AOM提供的文档和例子从而以偏概全，那也是AOM自己的问题，为什么它的文档和例子给别人错误的印象呢？实际上，产品的文档反映了他们自己对产品的认知，所以我认为基于此做判断是很正常的。况且我其实已经在努力往好的方面理解了。

2. 我为什么要提“id变”的问题，怎么还不理解内？说的再明白一点，我是点明了一个事实，绑定约定总是存在的。区别是绑定的表达能力如何。框架的作用就是找到一个平衡点，并确保或至少引导开发者始终保持在这个平衡点附近。AOM或许认为el的设计不好，无非是认为网页设计者或曰美工用不来或者根本不应该用el，这种看法或许是有一定道理的，但是可惜的是AOM的同志在这里只是基于一个浮于表面的感觉（当然也许他们有更深入的理解，但是现有的文章是故意写得浅白，从而让我们无缘得知他们的更本质的思考）——比如说，我就可以问，既然认为美工不应该用el，那为什么美工应该用taglib或任何除了html之外的markup？

你还追问id为什么要变，我真的懒得回答了。我就问一下，这里有谁写好java类之后从来不改类名和方法名的？难道就java开发人员掌有“命名”事物的权力，而美工和前端开发者就没有？id可以充当粘合剂不代表id就只是粘合剂。

3. “IoVC与传统JSF的分别，就在于让程序员在java中管理耦合点id，还是由美工在页面去管理el。”

这个总算说到点子上了，AOM的文档如果能大白话的写那么一句，我们就不必浪费那么多眼神和口水了。

我得承认，IoVC是符合一种思路的。这种思路就是，view只是花架子，是美工托托拽拽画出来的，view的本质是不可控的，是obscure的。但是你又要控制它，所以用id打下楔子，然后由java代码灌注意义和灵魂。

就简单的一对一填充数据来说，IoVC完成得非常好，这个不用说了，但是遇到稍微复杂一点的ui logic怎么办？好了，AOM出hack了，第一招叫做attribute侵入，第二招更狠，直接生成一些javascript嵌入进去。我其实还没有提别的问题，比如我一个view上要用一个model的两个不同的instance怎么办？我猜他就是换一个attribute来侵入，或者还有其他狠招。

大家一眼即可以看出这些招实际副作用很大（model这样侵入ui，那能好得了嘛——除非你这个model就是专为view服务的），AOM自己也知道，所以名之曰约定“优于”配置（提醒同学们，我这里的修辞手法叫做“双关”，千万别给认成了“反讽”）。

BTW，我现在挺反感拿约定配置来说事儿的了。你的约定要是基于过分简化不切实际的假设，那约定得再简单再漂亮也就一个词：意淫。我记起有人叫我给“统计数据”，太搞笑了，“统计数据”不问打着所谓“约定配置”旗号的同志要，管我要？我只要求给个像样点的例子，那边倒好，言之凿凿的问我要“统计数据”，我想我真是太善良了点。

言归正传，我们回到IoVC的理念。其实就一个，在AOM眼里，view就是一个架子，根本没有logic的。

这种思路并不是完全没有可取之处，但是IoVC有两个大问题，这说明他们没有把深层次问题想明白，而只顾着所谓“方便”。

第一，就是用java来bind，导致ui的约束崩溃了。虽然他像模像样的说，我们没叫你把style写到bean里——废话，JSP也没叫你把jdbc写到JSP里。事实上，连IoVC自己的例子都被袁老大点评成了“有问题”。AOM自己的人都要用豁边，何况普通开发者？

第二，抛开前面这种情况，我们假设IoVC是把与纯粹的ui控件（空架子）无关的部分解耦出来了，放到了model里。问题来了，你的model到底是什么model？

我随手写的例子其实就是要说明这个问题，解耦有很多方法，但是我的方式是有约束的（我采用了定义好的xml tag，同时既有的el也是一个约束，他阻止了我在这里写jdbc——当然也可以用其他方式约束），那就是model是view的model，它是从属于view的。而IoVC就没有这种约束了。AOM有一个名头是@LiteBean，这说明他们认为这个东西应该是lite的，但是他们没有意识到的（或者他们偷偷藏起来没告诉我们的）是，从ui解耦出来的所有“绑定”都应该是从属于view的。如果他们意识到这一点的话就应该把这个命名为ViewBean或者干脆FormBean。

这两个错误归根到底都是缺乏约束。或者再说得玄虚一点，就是缺乏合理的philosophy。什么都可以实际上就是什么都不可以。

4. 关于我随手写的例子。

“同一个view里无端的多出一个间接绑定，仅仅是把el堆到一起，有什么实际意义呢。”

有什么意义，意义就是达到IoVC所希望达到的别让el去烦美工的想法。用术语来说，就是隔离ui控件和所需的数据源、action等。

但是，不同于IoVC的有三点，第一，我明确这是view的一部分；第二，我不会打破ui约束（代码里没有完全表现出来，但是可以说一下，我不会允许所有的markup都能binding，bind属性只能用于特定的markup）；第三我保持了bind的灵活性，但是又不至于无法无天（谢谢你告诉我@Bind可以绑方法，我终于可以写jdbc啦！）。

“难道同一个文件头部和正文由不同人去编写？cvs里的冲突警告可不是用来看着好玩的”

当然可以由不同的人去写。逻辑隔离不代表物理上一定要分离。关于CVS，无语了。不同的人写不同部分如果会产生conflict，那要CVS干嘛？？？

“也许这里也只是举了个不恰当的例子，在真实应用中，你会把例子中model的定义部分分开”

我的例子没有任何不恰当。model是不是要分在一个独立的物理文件里，是由实际需求和团队分工所决定的。

甚至，如果是我写ui，而且ui需要的bean都简单得跟IoVC的例子那样，我根本不会把bind单独写到model部分里，而会直接在markup上用el。只有ui涉及的数据源较为复杂，我才会用bind来映射，以便提高可维护性。

“欢迎你加入IoVC的大家庭，这正是IoVC在做的事。”

IoVC或许想做这个事，可是做得不得法。等他做得法了，我再加入“大家庭”不迟。

“唯一不同的是，IoVC的绑定使用了你认为一定会变的id，而你的例子使用了一个红色的bind属性，这个实现细节我看来是无伤大雅的，只要你说明了为何 id一定会变，有理有据的话，我想AOM的开发人员可以接受改用另外一个随便什么名称的属性来作为耦合点，这应该是举手之劳。”

这根本不是实现细节的问题。

应该在ui control上用bind属性去绑定bean的实例，而不能反过来让java class去根据id填充ui control。最简单的例子：两个ui control绑定相同的bean，难道你要他们有相同的id？好，你说我换一个属性，比如class吧。那我另十个页面上已经用id绑定了耶，怎么办（还认为这是“举手之劳”）？如果两个ui control要绑定相同bean的不同实例又怎么办？

“能在模型端享受强类型检查的做法是退化，你的model文件要写个无编译期检查的接口签名还要写个id的做法是进化，没想通，希望能展开论述一下。”

我说的退化是IoVC的类没有规约，回到了洪荒状态。强类型检查很了不起吗？虚幻假象！你是不是一并检查一下你的html里的id拼对没有呢？想想吧，这个根本不可能，你怎么知道我写了一个id是为了给你IoVC来侵入的，还是派别的用场的？你的耦合点根本就脆弱不堪。

相反，我的随意的例子里，是可以通过工具检查出bind的有效性的。如果bind属性和bind元素的id匹配不上，就说明有错误。el也是可以检查有效性的。

“看来hax兄确实是忙于发贴，没闲工夫去下载个AOM试用一下。”

光看光鲜文档就有许多问题，你说我干嘛要去试用它？

“又用了@BeforeRender来对result赋值，就断定IoVC只能绑field”

我确实是这样推定的。因为AOM那篇文章就是这么说的。

“在AOM 2.0下，连 setter/getter 方法都没有？是的，完全可以忽略。……那么，result 的值是在哪里设置的？请注意 settingValues 方法，它有一个 @BeforeRender 的声明”

你说我不相信他们自己的文档还要相信什么呢？

如果说可用get/set，为什么不写成getResult()呢，难道就是为了拽一拽一个叫做@BeforeRender的莫名其妙的annotation？我其实还想问，既然不是因为这个原因，那么@BeforeRender有什么用？

“hax兄看待例子的态度，好象与一般人大相径庭呀，这也就难怪AOM的同志们举不出令你满意的例子呀。”

我来看例子，不是看他的使用方法的。而是要看他的理念。如果你认为这是大相径庭，那也没办法。

例子很糟好像也不是AOM的专利，前面所谓“google的ui不变”的例子，就实在让人很无语。请问google这样的ui要IoVC干嘛？它什么web框架都不要，一个最简单的html就完了。捡软柿子捏也没有这样的，我还能说什么呢？

-------以下是无关紧要的部分--------------

“让@Bind可以打在类上，打了@Bind的类，如果内部没有使用任何field级的@Bind标注，则默认所有域是绑定域。”

他已经有@LiteBean了。

“如果任何东西都约定默认绑定，那么难道我要配置时，要把所有不绑定的东西都打个@NotBind标注？”

需要么？按照IoVC，一切都绑定又怎么样？你view上没有id不就好了。反正IoVC的说辞就是“约定优于配置”。

“更好的判别策略？愿闻其详。”

不需要（见上一段），或者public/private。反正说到“约定优于配置”我就发笑。

我为什么说他心虚，前面已经说得很清楚了，不再赘述。

补充回一下以前帖子与技术关系不大的内容：

1. 为什么要把句子挑出来说。因为辩论要有针对性。无的放矢确实是无敌方式，因为放之四海的空头大话谁都会说。

2. 偶没有光批评，偶也给出了我认为合理一点的做法了。大家对比吧。

3. 为什么要说例子无力？因为举出来的例子真的无力。本来个例就不一定能说明问题，偏偏连个例都举不好……

4. 还有我要的例子是技术例子，不是什么钉子锤子、青蛙烧饼这种。而且如果要说这种，我建议直接一点，咱老祖宗有成语的：“井底之蛙”。不过MVC不是我们扯出来的，是AOM自己硬要扯上去的。前面许多同志只是批评它不要“指鹿为马”而已。

5. 稳定不稳定的问题偶不想扯了，想不通的朋友可以问问袁红岗“表现层稳定还是业务层稳定”？

6. 其他问题有意义的部分前面回答过了。没意义的部分……那自然就不用说了。

同意此观点。你们这种做法，实际上跟ASP.NET走的是同一条路子。不过同时大家也知道的是，微软现在已经意识到ASP.NET的结构是有一些问题的，于是又有了ASP.NET MVC，微软正在逐步走回正统框架的路子。这个东西，如果做得好的话，是能够对快速开发起到一定效果，但的确算不上什么新思想了。

我本人对这种思路是比较不感冒的。目前的客户端技术，包括Ajax、Flex和Silverlight，都有一个极大的共同点，即不依赖于特定的服务器端实现，无论 Flex+.Net 或 Silverlight+ROR 的组合都是毫无问题的。表现层技术能够脱离对服务器端编程语言的依赖，独立实现自身的发展变化，我认为是一个很好的现象，也应当是未来的趋势，对于这种试图将表现层纳入服务器语言强力统治版图的实现思路，我认为它是在开历史的倒车。当然这可能也有我自己的一些偏见在里面，算是一家之言吧。