谈谈J2EE开发（一）

     J2EE－－java世界中永恒的话题。或许是sun的失败，造成了J2EE世界中的无序。做了几年的J2EE，实在懒的谈了。 毕竟，技术并不是一切。工程，项目的成败很多时候和技术无关。太多技术的争论，分散了我们对其他问题的注意力。

    在当今的WEB开发中，MVC已经成为事实标准。如果那个framework说不支持MVC，必定遭到一堆人的鄙视。那我们今天就谈谈MVC。

MVC将一个交互式应用分为三个组件。模型包括核心功能，视图向用户提供信息，控制器处理用户输入，视图和控制器共同组成了用户接口。变更－传播机制保证了用户接口和模型之间的一致性。

语境：具有灵活人机接口的交互式应用程序。

问题：用户接口容易改变。

限制：（1）相同信息在不同窗口有着不同的表示方式
            （2）视图的显示和行为必须立即反映出对数据的操作。
             （3）用户接口易于改变，甚至在运行期也允许改变
             （4）支持不同的式样和感觉，移植用户接口不影响应用程序内核。

缺点：（1）增加复杂性
      （2）视图和控制器紧密相连。几乎无法独立使用。唯一例外的是只读视图。
       （3）视图，控制器与模型的紧密耦合。模型一旦改变，很可能导致视图和控制器无效
       （4）移植用户接口时，视图和控制器几乎不可避免的需要修改。
      
优点：不说了，上网一搜到处都是。

Swing是MVC的一个典型应用，抛开Swing的效率不说，还是比较成功的。个人感觉一定程度上是由于model的相对稳定性。

对于WEB来说，受限制与http协议的无状态特性。用的MVC是一个变体，没有实现模型到视图的变更传播。而WEB这种瘦客户端应用，导致很多需要页面实现的功能转移到了服务器端。从而一定程度上破坏了MVC模式的优雅性。而Swing中的model的概念和J2EE中model的概念也存在了很大不同。在Swing的实现中，model指JList等数据结构，相对稳定。J2EE中，model代表业务实体。而业务实体的不确定性，导致J2EE中model的相对易变性。从而带了更多复杂的因素。

    在很大程度上，虽然MVC有着很多优点，但MVC并不是解决J2EE应用复杂性的银弹。面向组件的J2EE解决方案或许才是真正值得我们所期待的。不过，当前的Tapserty，JSF还未能完成组件化的目标。只能说“革命尚未成功，同志还需努力”：）