IoVC，一种新的编程思想

例子举的太狭窄了...

不敢苟同啊。在domain模型控制UI？这是MVC还是MV啊？
按你前面的介绍，应该是控制层才合理。
MVC的目标就是解耦，可你公司的IoVC看起来不像啊，而是越来越耦合了。

支持，真正理解原理的人都会有此结论。
再次提醒下，不要打着MVC的旗帜，实际却作的反MVC模式阿。浪费时间精力。

这要看你怎么理解MVC。

我是这样看待MVC的：MVC的最终目的是让我们的程序结构分层解耦，从而让应用系统的可维护性及可扩展性增强，而将程序结构分成Model、View、Control，只是一种手段，而不是我们的最终目的。

在带有界面的应用系统中，UI和后台逻辑之间的双向交互，无疑是必须的一种基本能力。

IoVC，使你具备了这样一种双向的能力，但这种能力怎样运用，用在什么场合，则需要具体场景具体分析。

记得我曾经给客户演示过这样一种场景：
当用户在某个textField中输入了一个错误的字符，用户希望让textField的字体变成红色。那么，在IoVC下，我们可以这样做（假设textField的id为abc）：
在后台的ManagedBean中，声明一个变量：

@Bind(id="abc", attribute="style")
private String txtStyle = "color: red";

如此一来，我们可以在不更改页面的情况下，满足用户的需求。
但这样做是否就是最佳方案？
笔者看来，也未必。因为类似于 style 的这种东西，确实是应该放在 UI 层，而不应该放在后台代码中的。

再次重申：IoVC，只是让你具备了这种能力，但具体怎么运用，需要具体场景具体分析。

之所以前人总结归纳了那么多的方法、原则、模式、架构，就是避免出问题的，当然随之而来的是较高抽象度和实现复杂度。

现在如果为了实现的方便有意违反的话，也大可不必打着这些模式的旗号，会误新人的。

这样明显的有意违反，其实可能是换取在某些特殊情况下的方便（如你所说，可能让客户感到非常满意），但是不见得能大力推广吧？（这样的便捷一般都是在特定情况下，一旦超出带来的就是麻烦了）

我再举一个场景：
假设我们的应用系统需要支持中文和英文两种语言。诸所周知，由于中英文的差异，会导致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}"/>

哪种方案更优雅一些呢？

具体点说，这类东西在很多公司内部都有有想法的人做过，
我见过另外的一个私有框架，完全是根据数据库结构生成中间层和表现层代码模板，可以做到数据库字段如果是not Null 的，html表单中就会自动加*显示，提交时自动判定必添字段给予提示...
这个东西不是更省？对于简单的CRUD程序，每次修改时，改改数据库定义重新生成一遍代码，基本OK了。
但是有很大的推广意义么？它只适用于很窄的范围，如果遇到意外情况，就必须修改框架来适应（框架本身不具有广泛性和稳定性），而除了框架作者，其他人恐怕也很难在这种情况下快速修改和调整。

再具体到刚才的style的例子，其实怕是更加思路不清了。
当前的web基本上都要走DIV+CSS的路子，CSS的麻烦不比javascript少（相对于以前的table布局，抽象不直观，又有跨浏览器的问题，当前的2.0还有些限制不能100％随意布局），但是有一个好处就足以让我用它了，那就是可以让web随意换肤，而只要改动一行html就行了！
看看刚才的例子，如果都把style写到java code里面了，还怎么作网站换肤？
必将是这样一种情况：界面的些许改动，都导致java的代码变动（要重新编译，重新部署），这就是不遵循前人经验的恶果吧。

－－－－－－－－－－

口气有点重，希望是良药吧。

确实，很多私有框架在解决某些特有问题的场景下，会更方便，笔者也见过许多。
同样，笔者对这些私有框架也并不感冒，究其原因，无非：
1) 这是一种强制性的框架，你只能选择Yes或No。而一旦你选择No，就意味着框架带给你的好处全都不见了。
2) 这是一种约束性的框架，只能解决某些特定场景下的特定问题，一旦你试图将这些场景扩大，你会发觉，
框架会给你这样或那样的限定条件。
但IoVC则不同：
1) IoVC不是强制性的，你完全可以利用它，你也可以抛弃它。IoVC并没有阻断你解决同样问题的其它途径。
2) IoVC是一种相对而言比较"general"的解决方案，它不会限制你必须要遵守什么约束。
再次重申：IoVC使你具备了一种UI和业务逻辑双向影响的能力，但你怎么用，在什么场景下用，则是仁者见仁智者见智了。

举的例子太狭窄，看不出有什么好的地方
后台本来是管理数据的，现在还要来管理前台显示，已经违背了MVC的思想了