IoVC，一种新的编程思想

不过web中确实view无法监听model。这个可能是与传统CS结构下MVC的最大区别

1. 大而化之的道理就不用说了，每种技术都有适用场景，那不是说每种框架都有道理么。那我们费什么口水呢。

2. Web上的MVC的一大弊病就是与经典MVC相比，controller变得太胖了，操心它不该操心的问题，比如它太操心UI。controller符合思维连贯性，这是在遇到带有状态的流程的时候是这样的。我倒是认为这没有什么局限不局限的问题，思想没有局限，架构才是有局限的。所以关键是你怎么实现它。

3. 你说jsf无意取代mvc，这个有点搞笑，又有点无力。

4. 你说效率和优雅的矛盾不知道是指什么效率。如果是开发效率，那怎么会与优雅矛盾呢？我还没见过不优雅的架构能提高开发效率的——除非以可伸缩性和可维护性为代价——也就是一次性的“和谐”项目。你要说最省力，那就是无为——我不做，我找外包做，嘿。

5. 要更猛烈，那你得先提供更多靶子才行，呵呵。

贡献一个我年轻时代关于MVC的学习过程，供大家参考批判。

发信人: HAX(海曦), 信区: WebDevelop
标  题: Re: MVC在WebE的对应
发信站: 饮水思源 (2002年07月11日19:19:49 星期四), 站内信件

今天继续看了一下，又有一些新的发现。

【 在 HAX (海曦) 的大作中提到: 】
: 今天看了很久以前down下来的一篇文章：
: Objects and the Web
: Alan Knight, Naci Dai (这个名字好像中文名字啊！)
: 其中提到Web分层构架是4层：
: Input 对应于 MVC 的 input controller
: Application logic 对应于 application controller
: Business logic 对应于 model
: Presentation 对应于 view

传统MVC起源于smalltalk这种语言，用于软件开发。但是我们对smalltalk
不了解，很多对方也对MVC想当然，而且有绝对化（神化）MVC的倾向，
但是今天重新看了一下Objects and the Web文章里的图，据说MVC中的
Controller原来只是控制Keyboard、Mouse的，也就是说只是Input Controller，
而且Web上的Input Controller的对象显然不是Keyboard之类而是HTTP的Request
（所以好像看到有熟悉smalltalk的同志抱怨此MVC与stucts实现的MVC不同）……
而且更重要的是原始的MVC中并没有显然的区分Application logic 和
Business logic！仔细想想也是，Smalltalk就是学院式编程，恐怕没有
中间件的概念。

请问诸位同志在学习编程的时候有意识的区分Application logic和
business logic吗？我猜想达不到大量复用和构建复杂应用的需求时，
不会有自觉的Application logic和Business logic的划分吧！

: 俺觉得以前好象对这个对应没有搞得很清楚。主要的问题是
: 对于Application logic跟Business logic有些混淆。因为
: 还有content-logic-style的分法。事实上现在明白了，复杂的
: style还包括presentation logic，而content-logic的分法是
: 与model-controller的分法有差异的。因为对于传统web来说
: 它只有人可以理解的content没有设计model！当然这个判断不
: 是绝对的。因为content(data)既然成为独立的层，好歹会有
: 一些model，但这个model通常不是像MVC中那样是OO的，一般
: 可能仅仅是结构化和半结构化数据，或者是像ER model。显然
: 如果是这种情况，business logic就不能被封装到对象自身，
: 于是就容易与controller(application logic)混淆起来！

这里有点没有说清楚，content-logic和model-controller是有不同，
但是有类似的问题。前者的问题是application logic和business logic
混入logic层（我判断原因是content缺乏oo的表达），后者的问题是
application logic和business logic混入model层（或者毋宁说是还没
有application和business的分层需要）。

: 可是有个疑问，web的content不选择oo model，就一定是错的吗？
: MVC的分层一定适合于WebE吗？我虽然还没有答案，但我倾向于
: Web上需要应用的是一种非传统OO（如RDF）的model。

最后的意思是oo好像也具有封闭性……但是这个想法还很不清晰。


欢迎大家讨论。
--
做系统缺少资产，做应用缺少沟通，做信息缺少分类，
做工程缺少规范，做管理缺少制度，做团队缺少组织……
※ 来源:·饮水思源 bbs.sjtu.edu.cn·[FROM: 202.120.15.34]

其实我是针对他说的来对应的说的。这个话本身不严谨。

MVC不是那个部分强不强。因为MVC本身是个架构模式，每个部分并不对应到具体的实现。按说是不存在强不强一说的。我的所谓强不强的意思，其实是指在一个实现MVC或者MVC变种的具体框架里，它的MVC的职责划分是怎样的。

现在至少有两种MVC，一种是经典MVC，一种是Java的Model2。这两者是有差异的，他们对于MVC职责的划分是不同。甚而我觉得其实现在的Web MVC与经典MVC有很大的差异。比如经典MVC是基于观察者模式的，View会注册Model的事件来自动管理自己的刷新。但是传统Web MVC是没法从model推送事件到view上的。所以这个职责就被搞到controller里去了。

按我的看法，这是无奈之举。否则就不会有现在大家都要搞event-driven的web framework了。

所以Web MVC的问题在于View太弱（即职责被弱化了）。这是削足适履（适应HTML/HTTP）的过程。
也就是说，现在不是view不堪重负，而是根本不堪弱负。

这里有一点，尽管经典MVC和web MVC是不同的，但是有一点相同，就是model都是不依赖view/controller的。这也是前面许多同志质疑IoVC的地方。因为他在model上标注了对view的具体细节的映射。那我view变化了，model也要变化了。如果你只是要将一个特定组件与数据源绑定起来，那为什么不是在组件的markup里去绑定数据源，而反过来在数据源里去绑定组件？

model修改而view修改，这是所有模型里面共性的，也是情理之中。model修改意味着你的需求（业务逻辑）变化了，那业务逻辑变化，界面十之八九是要随之改动的。另外一点，后端也是可以分层的，我们这里只谈跟controller发生关系的model。

所以很少有人担心model修改而view修改，而会担心view修改引起model修改，这个连锁反应就大了。这个我们都有体会，只听说美工改了页面，程序员挠头，很少听说过程序员改了java类，美工挠头的。呵呵。

你说的完全正确。web框架的思路成了：html只是render出来的结果而已。View是咱自搞的一套（轮子一套一套啊！）。模板标签等等都是我们用来抹杀BS鸿沟的手段，可惜最终都失败了。现在的指望就是jsf或类似之类的方案，他全盘抽象，你甭写html甭写js。你写我的组件，我帮你翻译。至于做出来的效果怎样，你要相信我的renderkit嘛。

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

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

就是IoC嘛 有分别吗? 只是在视图层用而已~

感觉这种tag比较费解。。。。通过注解都不知道页面对应bean的什么属性去了。
真的与其学这个，不如更加大胆一点，html更纯净一点

一个字，难！
据称在ROR早期给予component很大希望，但在后来几乎被完全抛弃了。
传统web的东西（非ajax）不可能完全和C／S GUI程序一样。
如果认识到这一点，或许接受html,js,css配合模板式view，是一种最好的选择。

（不过最近的js／ajax框架，如ext之类的，到像是把web变成了基于浏览器平台的c／s编程。这个还在学习中，不多说了）

看了这么多回复，觉得这段话真是完全反映了问题所在。对IoVC的质疑声音，大都是集中在它没有遵守MVC在多年前灌输给我们的一个假设：展示层必然比模型层易变。事实上真是如此吗？其实未必，坦白说用google快十年，就没发现它的展示有怎么变过，MSN web邮箱也是用了这么久只变过一次。各大门户网站，虽然内容在天天变，但展示层发生根本性结构变化的次数，屈指可数。至于一些相对较小的电子商务网站，既然运行良好，很少看到有没事变着界面玩的（当然变化是有，但通常都是业务需求发生了改变，这种改变十有八九会触动业务逻辑，是表现层和模型层一起变）。相对来说，业务模型的变动，其实是频繁得多，我相信这点没有人会否认。这些变动有的是必然会影响到表现层结构的，有的则未必，但在传统MVC中，只要业务层一变，或者更具体点，只要业务层到展示层的接口一变，展示层就必然要跟着变。这是现状。我并不是一口咬定业务变动必然比展示层变动多（虽然事实很可能如此），但至少没有任何迹象表明，展示层的变动必然比业务变动多。

其实纵观当前大多数关于分层架构比较稳重的说法，对于view的分层并不是因为它的易变，而是因为它的多样。也就是说你往往需要为同一个业务模型设计多个展示，并同时运作，而不是说你会有一个或多个展示在业务模型稳定的情况下，不停地变动。这个帖子既然已经说明了在探讨web展示，那么就不应该担心除web以外的其他展示（如果一定要担心，正如楼上某位所说，需要把JSF的后台bean看作一种页面bean，只在里面放页面行为逻辑并调用业务逻辑。而其他展示则直接调用业务逻辑，这是在这种场景下必要的分层。这时即使你不用JSF，都应该把界面行为与业务行为明确分离）。而如果只在web展示的范围内考虑多个展示，那么如何让模型的变动尽可能不影响到展示，则更为重要。因为如果模型变动必然会影响到展示，一个模型变动会导致N个展示跟着变。

那为什么在这种情形下，还会有一大批程序员从小就认为展示层必然比业务层易变呢？我觉得有一句话非常能说明问题：“如果你手里只有锤子，你会觉得一切东西看起来都象钉子”。从小我们的C语言的老师就教育我们：“不要在计算加法的函数里写printf，因为要分离展示与逻辑。这样有什么好处？如果明天我们要把文本输出的东西改为在图形界面输出，只改负责输出的函数就可以了”那为什么他不能说如果明天我们要把数字加法改为字符加法，只改算法函数就可以了？原因很简单，负责业务的函数的输入类型和输出类型都发出了改变，负责输入输出的展示层逻辑必然要跟着变。从这个方向来看，分离根本没有任何意义。再深入一点说，传统的分层，事实上是一种服务提供者与服务消费者的分离。服务消费者在服务提供者给定的约束范围内可以有限度地变动（服务提供者根本不知道消费者的存在，消费者要遵守提供者给出的接口协议），但服务提供者的变动则倾向于传递给消费者。

这个问题事实上到了MVC阶段也没有很好的解决方案，以MVC为基础的编程模型，是不会刻意强调“如果业务层变动比展现层变动要快”的场景的，道理很简单，因为此题无解。或者说，既然技术上不能解决，那么就从观念上解决。我们仔细来品味一下引文中的这句话“model修改而view修改，这是所有模型里面共性的，也是情理之中。model修改意味着你的需求（业务逻辑）变化了，那业务逻辑变化，界面十之八九是要随之改动的。” 这让我想起一个故事：某人找算命先生算命，算命先生说：“你命途坎坷，二十岁落魄，三十岁流浪，直到四十岁……”某人大喜:“四十岁如何？”“那时你就习惯了。” 改model必然要改view，已经成为一种习惯，一种“情理之中”，程序员们在习惯中痛并快乐着，已经来不及去管这种状况是否必然，是否合理，甚至会对试图解决问题的人嗤之以鼻了。仅从IoVC着眼于解决这个多年宿疾这点，我觉得IoVC当之无愧可以称得上是一种思想的，虽然它尚处于雏形。但事实上当年谁也不知道，一个病人在床上无聊地发现非洲与美洲的海岸线长得很像，到后来会变成了地壳板块漂移学说。解决问题本身也许不算思想，发现一个多年以来放在人们眼前的问题并尝试去解决，则可称之为思想了。

以我到目前的理解，IoVC事实上并不是什么繁杂的框架，也没有什么很深刻的理论。它是从这两方面去解决上面的问题的：

首先是弱化服务提供者与消费者的耦合。如何弱化？通过id绑定，这正好回答了hax兄提出的问题：“如果你只是要将一个特定组件与数据源绑定起来，那为什么不是在组件的markup里去绑定数据源，而反过来在数据源里去绑定组件？” 在markup里绑模型，绑什么？绑接口。JSF的嵌入EL表达式，JSP的<%! %>，libtag， struct的url pattern。本质来说，都是嵌入在展示层的模型层接口。既然通过接口绑定，就必然涉及到接口签名，数据类型，命名规则，或者各种各样的约定，而这些规则约定天生是与业务逻辑耦合的，这种耦合只能弱化，不可能消除，一旦变化，必然传递到展示层。IoVC而在模型里绑展示层，绑什么？绑id，一个简简单单的字符串key。对于简单值，模型代码事实上不管另一端是什么组件，展示组件也不管另一端是个什么接口签名，例如一个字符串，可以绑在textField上，也可以绑在dateTimeField上；一个组件id，可以帮在简单的对象域上，也可以绑在public String getPersonName()上。程序员只需要告诉网页设计人员：“如果你想用个随便什么东西显示这个人的生日，请把那东西的id设为birthday”，或者反之，网页设计人员告诉程序员：“我这里需要显示个生日，请你在那个什么地方——好像叫做对象私有域还是属性什么的——指定个birthday”。如果是传统做法，程序员只能告诉网页设计人员：“请你在个可以显示字符串的组件上引用myBean.getPerson(id).getBirthday()。”，没有反之。IoVC也允许通过id来绑界面组件的模型类，并进行各种循规蹈矩或者离经叛道（例如指定style什么的）的动作，这里事实上没有什么新东西，如果你循规蹈矩，那么就是标准的JSF编程模型（这里只谈IoVC，不谈AOM其他的功能例如消除视图状态等）。如果你离经叛道，那么可以在bean里控制展示层任何东西，当然没有任何人（包括AOM的开发者）会建议你这样做，IoVC只是提供了在某些特殊场景下可以这样做的机会。这正如c语言不会禁止你写段代码低级格式化系统硬盘，但并不代表它推荐你没事就格式化。通过这样做，IoVC弱化了模型与展示之间的单向耦合，令它们可以分别独立演化。

其次，提供了将系统行为的发起点后移到模型中的选择。此话怎讲？我们知道，目前大部分编程模型，系统行为的最根本的发起点，是在展示层代码中。这个方案背后的原因很简单，简单到大部分编程模型拿它一点办法都没有：因为说到底系统行为的实质发起者是用户，而展示层是与用户交互的接口，一切用户的行为都要通过展示层传递给系统。在这种背景下，在展示层嵌入对模型的调用逻辑是无可避免的，这个发起点可能是一个EL表达式，或者一个特定形式的URL，或者一个taglib标签，或者一段JavaScript，由它去触发一系列的后续行为。这就形成了模型与展示的一个耦合点，再次涉及到接口签名，调用规则等诸多约定。只要这些耦合点存在，展示层就不可能脱离模型独立演化，而编写展示层的人员就必须与模型层人员制定一系列的约定，关注许多与人机交互毫不相干的东西。IoVC对这个问题的解决方案是，展示层设计人员只需要在页面上放一个button组件，或者一个link组件，或者一个TreeNode，随便什么东西，并指定id。他需要与模型程序员约定：“我会放一个id叫submit的东西……是啥你别管……来提交表单，用一个id叫birthday的东西来显示生日，你自己看着办。” 而不是由程序员跟他说：“如果你要提交这个表单，需要导航到这个url，如果你要提交那个表单，就要去那个url，其实很好记，它们前面的context root……就是域名加上/humanresource/那部分都相同，只是后面……还有生日这里需要写条表达式，你有没有带纸笔？”

AOM2.0还没有正式发布，以上只是我到目前为止根据一些资料和自己试用对IoVC的初步理解。但我觉得，即使退一步来讲，也许AOM2.0对IoVC的实现还不算完美，但它的着眼点是为一个已经存在多年，以致很多程序员都视若无睹的问题，试图提出一个自己的解决方案。这种气魄，以及它对国人开源社区的意义，是配得起思想二字的。