锁定老帖子 主题:IoVC,一种新的编程思想
精华帖 (0) :: 良好帖 (6) :: 新手帖 (17) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-03-27
allenBen 写道 感觉有点像WEB-work或者struts2,直接是页面从Action里边拉数据
好像不是吧,从贴的例子中看,页面上没有el表达式阿,页面通过啥方式从后台拉数据? |
|
返回顶楼 | |
发表时间: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即可。 |
|
返回顶楼 | |
发表时间:2008-03-27
pig345 写道 sxsxsx3 写道 引用 这种在后台影响UI表现的能力,还是不要有的好! 为啥呢? 我想他的后台是指model。 由于view和model的不同职责所在,不能让model管理某个特定的view的展现逻辑,这样既会造成model的过分负担(如果有多种不同的view就更麻烦了),而又把view变成了白痴(连怎么展现自己都不能作主了)。 如果对应同一个model有不同的view展示,在表现层需要根据不同的要求来构造不同的view展现么?如果说在view中增加控制展现的逻辑,那么view的复杂度就增加了不少阿。 |
|
返回顶楼 | |
发表时间: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的复杂度就增加了不少阿。 |
|
返回顶楼 | |
发表时间:2008-03-27
问题是在于,即使是最强调实用、敏捷、快速开发的ROR都严格遵循着MVC的老路子,而没有反行之,应该能说明点问题吧。(ROR倒是把3层结构给抛弃了,不像j2ee还很强调多层)
apusiczhang 写道 其实笔者一直想强调的是:应用系统的可扩展性及可维护性,是我们的焦点所在;而MVC只是我们的一种手段,一种模式。 如果非要用Model、View、Control这三个东西来往IoVC上套的话,那么,我感觉:ManagedBean,其实更像是Control,或者是Control与Model的混合体。 至于pig345兄所提到的:同一套应用逻辑(这里的逻辑二字,有些含糊,恕笔者口拙,无法详细阐述,但想必不少朋友应该可以理解),如果需要两种不同的面貌(html?xml?),其实这在OperaMasks中是再简单不过的问题:UI是基于组件的,我们更换一下组件的RenderKit即可。 |
|
返回顶楼 | |
发表时间: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的展示好像能避免重复的代码出现。 |
|
返回顶楼 | |
发表时间: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的耦合度而已。 |
|
返回顶楼 | |
发表时间:2008-03-27
对于楼主提出的IoVC+jsfc,感觉同Tapestry有点类似阿,难道真的可以让美工和程序员之间的关系变的更为松散么?还有一个问题就是jsf由sun推出后,一直感觉有气无力的,看楼主的介绍感觉这个东西和jsf还是有着联系的,不知道如何能打破目前jsf的窘境?
|
|
返回顶楼 | |
发表时间: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}"/> 哪种方案更优雅一些呢? |
|
返回顶楼 |
已被评为好帖!
|
发表时间:2008-03-27
apusiczhang 写道 首先请"pig345"兄再观察一下笔者的语句:我并不认为将style放到后台Bean是最佳解决方案。 但同时,也请"pig345"兄考虑这样一个问题:(我的这个场景举的可能也有问题,但时间紧,一时半会想不到更合适的场景) 假设用户需要这样一种场景,在某个textField中,当用户输入某些不合法的字符,字体颜色变成红色,否则,字体颜色是蓝色。 并且,对这些字符是否合法的判断,需要到数据库中进行查询对比。 请问,这种场景,怎样解决最合适呢? 再回到楼主关于换肤的话题,何谓换肤?是指不影响用户业务逻辑的情况下,自由的更改应用系统的UI风格。 但上面的这个场景,它已经不是“换肤”所能解决的问题,这个场景本身就是用户的一种逻辑。 这样的假设(红字蓝字)不是太过肤浅就是有意斧凿。下次用户改规则了,改粗体斜体了,你还改你的java代码里面的bind??? 你这个思路不过是说所有问题都拿java扛吧(让java可以控制你的ui)。我们也想用一种语言包打天下,但是这是不可能也是自寻烦恼的。 至于说所谓逻辑。这纯粹是逻辑不清。用户在提需求的时候他没有presentation/app logic/domain logic的区分是非常之正常的。但是身为设计开发者,认为对具体UI的具体改动也能属于某种逻辑,那就很有问题。对用于“和谐”的一次性项目我没意见,管你怎么做无所谓。如果用在real world应用中,我就不敢苟同。 |
|
返回顶楼 | |