MVC中被忽略的View层

现在市面上这么多的java web 开发框架，struts2,spring mvc,wicket,tapestry,stripes,click....随便列一些就很多了，在web应用开发和维护的时候，我们会关注哪些功能呢？

 

提到现在的web框架，我们的第一印象是什么？POJO controller？支持spring，支持guice，支持EJB3？至于View呢，我们支持jsp、freemarker、 velocity、JSF、xxx template，view层，也就tapestry有点性格，考虑了一些问题（后来wicket可以认为是"借鉴"他的理念）

 

 

大部分的框架，支持模板系统，就宣称我们的业务逻辑和展示是分离的，但是实际操作起来，这个程度上的分离还远远不够，要做好也很困难，但是现在，我需要一个View层的解决方案。

 

一些经常碰到的问题：

＊运营人员说：要修改一个链接和一段文本，因为在一个动态页面里面，需要开发人员来动手，于是在某个应用上（或几个）做分支，修改，测试，预发布，发布

   靠，我就改这么点东西，告诉我需要1个工作日，还得申请紧急发布（得老大批准）

＊开发人员说：UED的同学怎么又把模板里的一个变量给搞掉了，内容又不正确了（甚至是页面500了）

＊法务说：有个推广链接要拿掉，全给我找出来干掉！不然老板要被请去喝咖啡了。

 

要解决这些问题，我期望的View层能够：

＊很好的分离逻辑与显示，不是宣称，而是真正解决问题，不过还没想好是什么样子

＊动态内容和静态内容很好的分离，静态的资源有很好的抽象和管理

＊简单直白的开发维护方式

 

我是觉得咯。VIEW。本来就是不可忽略的。
虽然说，我们技术人员专注于业务逻辑的开发，但是，我们的结果始终是以VIEW的形式呈现给客户和用户的。难道你把结果System.out.println();???
如果我们技术人员能将VIEW和业务逻辑都在头脑中形成一套比较好的体系，那是很不错的。

感觉这个不是View本身的问题。而是应用不符合需求。
一些经常需要更换的链接和文本本来应该动态处理的，你把他们静态了。那么这么折腾就不新鲜了。
我觉得与其开发新的View技术，不如多做一个模块，把你需要管理的部分管理起来。还有就是模板模块化。比如一些公共部分做成页面块来使用。

简单的页面更新也可以考虑简化发布流程。

lz 可以看看 lift …… 它是 view first 的非 mvc 框架。
它满足 lz 的各种需要 …… 不过是否简单直白就见仁见智了。

通过xml将view层隔离开

jsp就是view层最好的解决方案哦^_^

是最快捷的解决方案吧。

我还是比较喜欢servlet直接print代码

wiki丰富化

就是页面的所有元素
都是用wiki可调的.

这样子业务人员才能真正的自己完成业务逻辑

PS:如果自己写html生成模板...我就用决对定位来布局元素.

tapestry才是最完美的view OOP。

楼主列的那些问题 完全可以再tapestry里轻松解决。