IoVC，一种新的编程思想

根本不符合解耦和的原则。典型的反模式。等于把html传播到model层。
再说了，现在web交互的要求日益提高，如果只是提升这点功能话，根本无关紧要。页面的事情应该让它自己作主。

现在看来hax兄的焦点已经集中在两点，因为上一贴和上上一贴相比已经没有什么新观点了: 1. 还是那个从第一贴就纠缠至今的问题，一开始叫“你给我把刀子就等于叫我去杀人”论，经过集中讨论，hax兄很大量地说不再追打了，避开锋芒，然后提出了一个换汤不换药的“框架即制约”论。这次hax兄看来是小心得多了。不再跟我探讨着个理论的合理性，而是直接就拿着到处套用了。2. 两个不同id的组件引用同一属性(本质上,是用了同一个el)的问题;

关于“框架即制约”理论，我想我在之前的每一个贴子都有专门讨论过，实在不想和hax兄再纠缠这个东西。如果还有其他读者没有被我们闷跑，顺序看到这里的话，我只想问问目前有哪个实际在使用的框架，是会在其能力允许范围内，人为地加入限制，试图用技术手段限制，来向程序员灌输分层理论的？你遇到这样一个框架，你会不会因为你本来不懂分层，要靠它来学习分层而去选用？在我印象中，分层思路最明确，最严谨的，而又真正试图做过推广的框架，叫做EJB2。现在有多少人在用？有多少人用得开开心心？以致于EJB3专门为了简化编程模型，引入大量的新特性。为了什么？方便，而不是限制。

即使以传统MVC的经典structs为例，它有试图去阻止程序员在Action类中写业务逻辑吗，它有试图阻止我在Action类中直接拼凑html流来响应吗？它只是不推荐你这样做而已。structs事实上提供了方便程序员编写controller层的逻辑，它的设计意图没有涉及view和model，而JSF的设计意图本来就统一了controller与view两层。那为什么structs在controller层与其他层引起的混乱的潜在可能，hax可以视而不见。JSF在model层与controller层引起混乱（也就是在Bean中写业务逻辑）的潜在可能，hax兄就得而诛之。我不想去做太深的猜测，我能想到的最好答案，应该是做前端的hax兄拿着的是UI的锤子，看到任何侵犯其领土的潜在钉子，都本能地要把它敲下去。到目前为止，hax兄随手提出的理想框架，是我所见第一个强调制约的框架，但我已经具体说过，这个框架，为用户，为开发者本身，带来了多少额外的工作量。这还是只从概念上去理解，没有牵涉到实际实现的细节。AOM是一个已经推出的实际框架，hax兄的是一个“我如果做产品我当然会提供这样的特性”的理想框架，也许这就是所谓实践家与理想家的分别。目前以我来说，我只能期待hax兄的新框架早日问世，将全世界引向分层思想的大同了。

这里简单答一下hax兄关于“请问你，你这里到底检查了什么东西？有什么用？”，这里没检查什么特别东西，就是普通的java强类型检查而已。只不过IoVC的框架可以很方便地直接应用IDE或者javac本身提供的类型检查，没有给自己找麻烦。“我如果做产品我当然会提供这样的特性”，如果是指你自己写类型检查工具的话，我想具体问问你打算给多少种IDE工具写？每种工具升级带来的插件冲突你是否维护？答案应该是“我如果做产品我当然会负责维护”。嗯，偷偷告诉你，如果我不写程序去做火箭，现在人类已经登陆火神星了，别让外国政府知道，我怕被绑架。

关于id的问题，关于@BeforeRender的问题。本来我一直在看这个贴子，对于之前一些一看就没用过JSF，完全不了解JSF编程模型，把JSF标准与普通MVC不同的特性归到IoVC头上的贴子，我知道自己即使有针对性地回了也是有心无力的。你不可能叫一个没有用过JSF，但又因为某些原因反对JSF的人，先去了解JSF再和你讨论。所以我第一条回贴，是大而化之地只谈IoVC。谁知hax兄一条逐句反驳的回贴，把大家都绕进去了，不得不涉及到JSF的编程模型时，才发现，原来hax兄不熟JSF。。。那很多问题根本很难展开讨论，如果hax兄真的有心情讨论这些问题，我建议还是先去搞清楚JSF的编程模型，然后我们再来讨论吧。

下面的话是和有兴趣了解AOM和JSF的朋友说的。

关于相同属性绑不同组件的问题，首先我觉得AOM不会阻止你走回老路直接在页面写el，但的确如hax所说，会在系统中引入造成两种不同风格的写法，至于这种做法的破坏性有多大，我是没有看出来，但事实上总会有人看到星星火苗，就联想到山林大火。那么这时，你也可以选择在ManagedBean里绑定组件对象，然后把el直接赋予它的value或bind属性。这种做法，IoVC本身只帮你绑定了组件，并没有自动根据属性创建el，el还是要自己写。（但反正就算不用IoVC也是要在页面里写el，工作量并没增加多少）

但一写到这里，我就觉得有人就会跳出来：“慢，你这叫attribute侵入，你们AOM提倡这样的写法，没有想过它的破坏性吗！”对于这个问题，我觉得这个人是既不了解JSF的编程模型，又不了解侵入。在JSF编程模型中，组件树是前端页面组件在服务器端一个映射，这个组件树在请求生命周期的第一阶段restore view中被创建出来，对应着提交请求时前端页面的组件状态。在生命周期的后续阶段，允许由用户本身或者JSF框架，对组件树进行各种操作，其中自然包括修改组件对象的属性。最后，在render response阶段，JSF框架再根据组件树创建响应信息（在http协议中，就是html页面了），然后响应信息被整个返回给客户端。这套编程模型是JSF的标准编程模型，也许与很多人心目中的MVC有差别，但是我在这里只能先给大家一个整体印象，JCP既然把它作为一个规范提出来，作为JavaEE5的重要特性之一，至少在编程模型上，它是能自圆其说的。关于侵入，我没理解错的话，应该是ajax出现之后的一个概念，说的是你在客户端发起一个ajax请求，然后前端js逻辑本来是打算将此响应赋予attribute，但程序逻辑将返回的响应信息作为javascript来执行了，或者是该attribute在前端渲染时浏览器会将其内容作为脚本执行，视为脚本侵入。这种做法据说是会造成很多问题，包括安全性，也包括编程模型（如果你故意利用这种特性来作为程序正常逻辑的话）。但这和JSF里一次性将组件树渲染为html响应发送回去的做法是完全不同的两件事。

但如果所谓的“attribute侵入”，是指所有在服务器端逻辑试图对显式改变（即使用el绑定，其值也是由Bean去决定的，只不过框架隐含完成了这个动作而已）组件属性的行为。那么这个问题也象上面关于JSP里用jdbc一样，不要跟AOM说，请写信给JCP讨论。。。当然，如果有人不吝赐教的话，我是很想了解一下这样做具体有何不妥，但希望讲述的人至少应该先熟悉JSF的编程模型。

经过连日来与hax兄的讨论，我觉得到目前为止我的观点基本上已经说明了。hax兄从一开始的“展示比业务易变”（最后结果：你自己去问袁红岗），到后来的“id易变”（最后结果：我懒得回答），到后来的“给我把刀子我就会去杀人”（最后结果：不再追打，换成了框架即制约的提法），到后来的“程序员需要引导”（最后结果：被忽略），再到后来的“框架即制约”（最后结果：没有讨论，直接套用），这些真正在“思想”层面与IoVC相关的问题，我觉得也已经做了充分的讨论。问题纠缠在用id绑还是用什么其他属性来绑，两个组件绑同一个属性时在bean里赋值el妥不妥这些实现细节问题，我觉得还是应该hax兄真正了解了JSF的编程模型后才有讨论的基础。因此如果没有什么新的论点的话，我觉得可以到此为止了，毕竟我的职业是写程序，不是在论坛上纠缠一些反反复复的问题。

思想归思想，我觉得项目或者某产品才能说话，拿出个开源的能说明新思想的DEMO来看看就能说明白了，谈思想和概念的时代已经过去，要和GOOGLE一样，技术推动市场，即便是简单不过的技术，人家用的恰到好处就是成功，就是核心，别走老程序员的死路，别再这里争论，没用，程序的世界不是争论的世界，是证明的世界。小弟一点点见解而已。因为我看了各方发言，发现了心态问题，发现了观望，也发现了关注，但太多的概念和思想还有不确定因素在里面，所以建议楼主DEMO一个不要太简单的东西，那玩意才有份量。

1. 已经说过的话，理解的人自然理解，不理解的人再说也没用。
2. 有些人总喜欢断章取义。我还说过要寻求平衡点，我还说过要解决最主要的问题呐。规约或者约束只是为了保障你的目标而已。如果你能有其他办法（比如你团队的人都是包身工，犯错你就要鞭刑）确保不走偏，那你确实不需要约束。
3. 恭喜你找到了一个struts的问题。这确实是实践中会出现的哦。不过我不敲它是为什么？难道是因为我厚此薄彼吗？非也，只不过本帖是AOM在自吹自擂而已。如果本帖是有人上来自吹自擂struts，我一样会敲——或者我不敲，因为已经太old了，大家已经没有兴趣敲了，偶就歇歇了。所以别拿struts来垫背。
4. “这里没检查什么特别东西，就是普通的java强类型检查而已。”
屁话，我问你检查什么东西，你告诉我就是强类型检查。就好象我问你你今儿早吃啥好东西了，叫我们都吃？你回答说，我就是吃了点普通的好东西，你也吃罢。我ft。
5. “自己写类型检查工具的话，我想具体问问你打算给多少种IDE工具写？”
这是个假设性的问题，而且又是一个只见ide不见实质的问题。不过我还是愿意回答你一下。如果我要写，我打算为0种IDE写，但是同时也是为所有IDE写。没错，就是0，但是也是所有的。认为我在打哑谜？好吧，咱点化一下，每个ide难道都要写一套自己的javac吗？我不打算做可能被绑架的超人，一次做好一件事情足矣。
6. @BeforeRender我已经解释过为什么提这个问题两遍了，但是有些人硬是要认为你丫不懂JSF，那我也没办法。
7. “那么这时，你也可以选择在ManagedBean里绑定组件对象，然后把el直接赋予它的value或bind属性。”
“在生命周期的后续阶段，允许由用户本身或者JSF框架，对组件树进行各种操作，其中自然包括修改组件对象的属性。”
太缺乏想象力了。请看看古老的XMLC吧。
我建议你不如不要写jsf，直接从java构造所有的组件好了。真正的纯粹的IoVC啊！注意，别误会，我不是反讽。我是说真的。它应该让我们直接写swing然后帮我render到web上，多好！
8. 为什么我不再说你所谓“思想”层面的东西了呢？嘿嘿，因为把人IoVC的皮剥一次足够了，没必要剥第二次。你看AOM的人自己都不作声了。我猜他们已经被我点化了，哈哈哈哈。

我再说点实际的。我虽然批评IoVC，批评AOM，但是我也没有说他们什么事情都没干对。比如用id绑定的初衷我认为也许是有价值的。但是做法有问题。我认为他还是可以改进的。

1. 明确litebean是用于每个页面的model，而不是业务层所暴露出来的model。不要让litebean有可能一身兼二任，并且要在文档中明确说明litebean不应该做什么。

2. 由jsf来主动选择bind，而不是litebean反向通过id操控。这可以解决我提出的那些所有细节问题。如果你希望有一种方式能够一定程度上控制jsf，就需要改进bind的方式。提示：可借鉴CSS和XBL的设计。但是无论怎样，你需要首先想好你的模式是怎样的，而不是祭出一个无法无天的特性就完事了。

3. 先占位一下。想到再说。或其他同志补充。

总算有点新意思了。。。

1. 同感
2. 目前有任何一个现有框架在这么做吗？除了那个虚无飘渺的理想框架。
3. 哦，原来搞了半天你是不满意人家的口气。。。谁冒头你就敲谁吗？
4. 包括但不限于签名拼写。
5. 希望早日见到贵框架面市。
6. 就是普通的JSF生命周期callback的简写形式。
7. 如果这是你基于IoVC的头脑风暴的话，我想AOM团队会考虑的。
8. 哈哈哈哈

1. 这点事实上符合JSF的编程模型，在原理上或者文档上我想AOM都可以这样告诉用户。但“不要让litebean有可能一身兼二任”，个人一来觉得技术上很难做到，二来也没有必要专门去做。

2. 如果你说的“jsf”是指前端页面（例如.xhtml文件）的话，这样做法事实上没有减轻程序员或者前端人员任何一方的负担呀，前端还是要管el，只不过多了个可以重用某个el的特性。但这种重用机会多不多，前端人员是否希望去关心这种重用，我觉得也未必。CSS体现的是内容与展示的分离，这层分离的意义是很明显的。但把el从bind的位置上分离出来而形成一个单薄的间接层，还是由前端人员去管理，目前来看并非很有必要。感觉IoVC的出发点之一在于，把el移到java的层面，让写签名的人去负责绑定，让美工腾出精力来专心设计。

另外，如果“我虽然批评IoVC，批评AOM，但是我也没有说他们什么事情都没干对”的话，我收回上一贴第3点。

1. 略。
2. 约束，什么叫约束？亏你还整天把强类型检查挂在口边。
3. 它有口气大家当然不满意了，让它多刷牙吧。
冒头未必要敲，但是如果要敲，你总不至于让大家这样，看到IoVC，我们大家一起跳出来狂扁Struts——“叫你丫MVC叫你丫MVC叫你丫MVC叫你丫MVC叫你丫MVC叫你丫MVC……”
4. 你检查的那些东西原来无法检查吗？你新加的id绑定检查还是不检查？你怎么检查？
5. 袁红岗来请我做框架的话，我会考虑考虑。
6. 还是答非所问。
7. 不幸的是这个方向已经有人做了哦。而且AOM选择JSF有不是基于技术的理由的，所以就算是好点子，也不见得会用。嘿嘿。

说说我的看法,我们把系统分层的目的无非就是结构清晰,易于扩展和开发维护,MVC也是这样的考虑,如果IOVC能够做到甚至做的更好的话那就是一个好的东西.否则就...

技术是为人服务的,必须要能很好的控制技术在实际中的应用,我不知道这东西就不乱说了,拭目以待好了.

ptw:说实话,要想开发的敏捷,最好的方式就是把层都打破,jsp里直接写sql,如果不考虑以后的话.

2. 语言约束和框架约束还是有所不同的。类型检查出错是违反语言规范。分层不同只是框架开发者和用户的理念不同，或者开发者想象中的场景与用户在实际使用中的场景有所不同而已。

3. 不满意要直接说嘛。。。不能说你不满意它，就把人人都有而你看不爽的特点（例如不提供框架级别的分层限制）去针对它。敲冒头是个人自由，我倒也不反对，但你叫的应该是“谁叫你冒头谁叫你冒头谁叫你冒头谁叫你冒头谁叫你冒头谁叫你冒头”，而不是“谁叫你两个眼睛一个鼻子谁叫你两个眼睛一个鼻子谁叫你两个眼睛一个鼻子谁叫你两个眼睛一个鼻子”

4. 我一开始提到强类型检查是在说你理想框架，既然你说你如果做的话会提供这个特性，其实没什么好讨论的了。

5. 不关我事

6. 所以我说你要先搞明白JSF编程模型

7. 有人在做不等于就不可以做。后发也有先至的，看武功如何了。现在我看国人做东西吧，你做个新的，有人说你冒头；你做个旧的，有人说别人已经做了。你低调吧，有人说你自己都没信心；你高调吧，有人说你口气大。上硬件网站看键盘广告居然还看到有人喷“你的这款键盘是抄袭人家双飞燕的。。。”（硬件的设计你如果没申请专利我有技术可以照做价格还比你低，第三者跳出来喷抄袭真是不知所谓。。。）看来中国人还是什么都别做比较不招骂。至于提到历史或者内部原因，我不了解也不想管，反正目前还算挺好用就是了。