OperaMasks有没有人用过？

OperaMasks这个东西竟然整合了Ext的东西

商业化排名不必在意，OperaMasks与其说是一个开发框架，不如说是一个开发工具，框架和工具有相当区别。

OperaMasks相关文章:
http://www.jdon.com/jivejdon/thread/28692.html
[该贴被banq于2008-03-19 14:52修改过]

IoVC——“Inversion of View-Control”，即“视图控制反转”，换言之：它把对“View（即 UI 视图）的控制力”注入到你的后台业务逻辑中。这样一来，你在编写业务逻辑的过程中，对 View 拥有足够的控制力，从而能够将展现层与业务逻辑完全的解耦。IoVC是一种新的编程思想，而 AOM 2.0则是它的完美演绎。正是因为IoVC的思想，使AOM 2.0拥有一种神奇的魔力！

不知道banq老师对IOVC有什么看法？

个人对IoVC比较谨慎，它实质好像是一个Ioc或者DI模式，看得出作者试图再往前走一步，但是真理往前一步就可能是错误。如果有程序员将界面具体元素耦合到业务层，那不是和将数据表名耦合到代码中一样嘛？如果这样做就违背了OO分离原则。

判断一个模式真伪其实就看其实质是否起到分离分派作用，我曾经批判Hibernate的Open session in view是伪模式，因为持久层的技术需要表现层配合实现，这将两个层耦合在一起，而不是分离。

Evans DDD中从架构高度提出了界面层和业务领域层/应用层和持久层，这个分层思想是从应用高度提出，MF肯定了IOC并为其改名DI以后，到目前还没有看到MF或Evans等建模大师进一步从宏观战略高度提出将界面层注射到业务层这样需求，MF倒是提出DSL这样面向建模人员的语言新方向，这个方向也是OO的进一步深化。

>如果有程序员将界面具体元素耦合到业务层
看了一下operamasks的案demo，感觉IoVC并没有把界面元素耦合到业务层，只是视图ID和表现层的action字段绑定而已，像jdon这样消灭表现层的框架，程序是否OO完全取决于业务层，表现层使用IoVC简化视图是否值得使用？

>像jdon这样消灭表现层的框架，程序是否OO完全取决于业务层，表现层使用IoVC简化视图是否值得使用？

我在以前文章说过，java复杂就复杂在表现层，我们看看其他两个主要层：业务层，业务层使用IOC后，就看你的业务，如果你的业务简单则简单；持久层：使用Hibernate后代码也很少，也很简单。那么为什么Java和ROR等相比还复杂，ROR和grails好在哪里？就是让你直接入手构建Domain。也就是让你更快面向业务编程。

所以Jdon框按照约定大于配置架消灭表现层，但是你还是可以使用配置来复杂定制表现层，不是真正消灭，而是在大多数情况下不必使用表现层了，这个和Grails将SSH缺省的配置封装起来作为缺省条件的思路是一致的。

那么有人会说，你这么简化表现层，但是客户对页面会有高要求，注意，表现层和界面是两个概念，表现层是一个MVC关系，我们简化了其中C，不必编程action，但是V试图ID等都可由美工等其他非技术人员实现，可以将界面做得很复杂。

从MVC这个模式意义可以看出，View视图是一个静态页面，是一个结果，作为一个流程的结果不应该和Action绑定，因为先有Action才有View视图；如果是视图提交给Action呢？这Jsp标准早就使用JavaBean解决，视图中数据肯定应该对应一个对象，但不是Action对象，它是一个struts的ActionForm，至于将ActionForm注射到Action中，Struts 2.0也做到了，借助Spring的IOC就可以，如果这个就叫IoVC，未免有点那个.....

对于Jdon框架，因为没有Action，就不必注射，岂不是更简单？

>视图中数据肯定应该对应一个对象，但不是Action对象，它是一个Struts的ActionForm
>View视图是一个静态页面，是一个结果，作为一个流程的结果不应该和Action绑定

如果是这样，老师可否透露一下整合jsf的jdon框架的设计，因为jsf不存在像ActionForm这样的模型边界，在jsf中的真正action又该怎样写？如果jsf+jdon开发完成，jsf这样的组件框架中的“组件”对jdon框架意义有多大？