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层能够：

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

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

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

 

评论

32 楼 zozoh 2009-09-22  

iaimstar 写道

要解决这些问题，我期望的View层能够：
＊很好的分离逻辑与显示，不是宣称，而是真正解决问题，不过还没想好是什么样子
＊动态内容和静态内容很好的分离，静态的资源有很好的抽象和管理
＊简单直白的开发维护方式

iaimstar 写道

前面说了，东西巨简单，简单到没必要有UI存在的地步，何况
我就是我们公司的美工～～，精通phtoshop丫

页面上的东西有两种：

1. 样子
2. 逻辑

样子用 HTML/CSS 写， 逻辑用 JS 写。
构建任何界面元素都可这样来划分。

数据来源也有两种:

1. 服务器直接渲染出的 HTML
2. JS 二次读取的 json/xml/dom 等

根据不同的需求，可以决定某一个界面的数据如何产生，一般的网站主要采用1，结合2。便于SEO。
B/S软件适合 2， 可以让开发更加简化。

在这两个思路基础上，在不同的项目中总结一套自己的 UI 解决方案并不是太难的事情。

31 楼 iaimstar 2009-09-22  

yirentianran 写道

wanglei8 写道

logicgate 写道

iaimstar 写道

logicgate 写道

iaimstar 写道

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

遇上复杂的ui，这么print岂不是耦合度太高？我觉得对于view层，越是复杂，就越应该把structure, presentation, behavior三者分离。

复杂的东西都是客户“毛病多”最后搞出来的

我们做的东西页面巨简单，连复杂的js都没有 木哈哈哈，jsp+include servlet最合适

同意，我们的客户就是毛病巨多，挑三拣四，老板也强调要user experience，结果愣是从瘦客户端慢慢整成了富客户端。

对于简单的页面，简单是最好的设计。

支持简洁之上

简洁是好，但是也要有一个度，如果真的servlet中直接print代码，
那UI来修改页面时候岂不是要看懂java代码。
如果UI不懂，那不利于协同工作。除非从前台到后台都是由你一个人来完成。
日后维护也是一个问题。

前面说了，东西巨简单，简单到没必要有UI存在的地步，何况
我就是我们公司的美工～～，精通phtoshop丫

30 楼 yirentianran 2009-09-22  

wanglei8 写道

logicgate 写道

iaimstar 写道

logicgate 写道

iaimstar 写道

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

遇上复杂的ui，这么print岂不是耦合度太高？我觉得对于view层，越是复杂，就越应该把structure, presentation, behavior三者分离。

复杂的东西都是客户“毛病多”最后搞出来的

我们做的东西页面巨简单，连复杂的js都没有 木哈哈哈，jsp+include servlet最合适

同意，我们的客户就是毛病巨多，挑三拣四，老板也强调要user experience，结果愣是从瘦客户端慢慢整成了富客户端。

对于简单的页面，简单是最好的设计。

支持简洁之上

简洁是好，但是也要有一个度，如果真的servlet中直接print代码，
那UI来修改页面时候岂不是要看懂java代码。
如果UI不懂，那不利于协同工作。除非从前台到后台都是由你一个人来完成。
日后维护也是一个问题。

29 楼 yinbaicheng 2009-09-22  

支持 简洁至上

28 楼 iaimstar 2009-09-22  

myseo 写道

iaimstar 写道

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

每次都得重新编译，很爽？

请把帖子看完，谢谢

27 楼 jansel 2009-09-22  

UI层本身变化很大，所以UI要形成一个通用的很难。通过看各个框架提供的Tag就知道了，只能处理数据，布局是很难搞的。

所以只要有Tag，那么肯定会和HTML Tag混合起来用，这样维护就成问题了。

个人还是喜欢Wicket的简介的方式，UI就交给HTML了。

26 楼 myseo 2009-09-22  

iaimstar 写道

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

每次都得重新编译，很爽？

25 楼 macllical 2009-09-22  

可以试下apache-wicket框架。显示和业务逻辑分离的相对而言最彻底。

24 楼 抛出异常的爱 2009-09-22  

solonote 写道

抛出异常的爱 写道

wiki丰富化

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

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

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

Wiki丰富化是指？异常哥可否说的详尽一些，或给点例子

wiki可以由文编发布
这样的话....很多程序员+美工所作的事就可以省下了.

还有就是多个模块排布时用决对定位的方式来排版....
那样子的页面生成器好写也可以防止跨ie ff等

23 楼 night_stalker 2009-09-22  

另外想要彻底消灭 scriptlet 是非理性的 …… 页面放大量逻辑固然很混乱，但是少量插入能省很多事。

例如 <%= f(1,2,3) %> 写成标签，就是 <f a="1" b="2" c="3"/>
本质上是同一个东西，jstl 最后也会被编译成 servlet print，连这种都改成标签有什么好处？

强制页面为 xml 就更没必要了，把 </html> 去掉至少能让想从你网站偷内容的人郁闷一下子。google 还故意让标签不关门节约带宽，每年省 3000 多美元呢。

22 楼 night_stalker 2009-09-22  

XSL 就是函数式语言了，复杂的原因是强迫写闭合标签和参数名，如果有 lisp 那样简洁就没问题了。

scala lift 就是函数式的框架，做的 view 和逻辑分离已经相当完美了。（虽然我觉得有点过于洁癖）

譬如说数据绑定的简单逻辑：

class A {
  // 自动产生可用的 <lift:A.f> 标签，参数 x 为标签的内部
  def f(x: NodeSeq) = {
    var a = "" // 闭包变量，对应表单域的值

    // 内部函数
    def process() {
      SomeModel find By(SomeModel.title, a) // 引用闭包变量做处理
      // ...
    }

    // 绑定命名空间 entry
    bind("entry", x,
      // a = _ 是一个函数，表单域改变时设置 a 的值，也能很方便改写成 ajax 的
      "a" -> SHtml.text(a, a = _),  
      // 提交时调用内部函数 process()
      "submit" -> SHtml.submit("提交", process _))
  }
}

在 view 中使用

<lift:A.f form="POST">
  <h3>填写 a 的值</h3>
  <p><entry:a/></p>
  <p><entry:submit/></p>
</lift:A.f>

21 楼 zhouxwyeah 2009-09-21  

也许XSL算是分离，VIEW都是用XML来填充展示，但是我也很烦XSL，感觉JSP最快捷，如果追求其他的什么东西，当然也要放弃其他一些东西。

  MVC+XSL或者其他模板，其实也就是把response得方式换了一下

20 楼 key232323 2009-09-21  

我觉得
data binding + template + ui widget
应该是个不错的选择

最近没时间，不过打算作一个

**mvc + web flow + groovy/freemarker + zk/extjs/jquery-ui ＋ jquery-ui-css/yaml

的ui端的聚合性高的东东的

当然，上面列的太理想化了，就最简单的，我能作好就满足了

19 楼 logicgate 2009-09-21  

对于很多系统，view层是最容易被忽视被认为简单，但实际上非常具有挑战性，也非常容易导致混乱的一层。

几年前看ajax in action的时候，里面提到一种nested mvc，我觉得对于业务系统的复杂ui来说是一个不错的实践。

18 楼 lkjust08 2009-09-21  

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

没有想好，就表明view的确不好分

17 楼 solonote 2009-09-21  

抛出异常的爱 写道

wiki丰富化

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

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

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

Wiki丰富化是指？异常哥可否说的详尽一些，或给点例子

16 楼 logicgate 2009-09-21  

wanglei8 写道

logicgate 写道

对于简单的页面，简单是最好的设计。

支持简洁之上

盲目推崇简单至上是不实际的。简洁至上的前提是你的设计必须能满足系统绝大部分的需求（包括客户的需求）。我觉得我很多时候都是在确保系统不过分复杂以至于降低开发效率和满足用户体验两者之间挣扎。

15 楼 liu78778 2009-09-21  

世间万物,
越靠近人, 就越复杂越难把握;
越远离人, 就越简洁越易掌控.

14 楼 wanglei8 2009-09-21  

logicgate 写道

iaimstar 写道

logicgate 写道

iaimstar 写道

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

遇上复杂的ui，这么print岂不是耦合度太高？我觉得对于view层，越是复杂，就越应该把structure, presentation, behavior三者分离。

复杂的东西都是客户“毛病多”最后搞出来的

我们做的东西页面巨简单，连复杂的js都没有 木哈哈哈，jsp+include servlet最合适

同意，我们的客户就是毛病巨多，挑三拣四，老板也强调要user experience，结果愣是从瘦客户端慢慢整成了富客户端。

对于简单的页面，简单是最好的设计。

支持简洁之上

13 楼 logicgate 2009-09-21  

iaimstar 写道

logicgate 写道

iaimstar 写道

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

遇上复杂的ui，这么print岂不是耦合度太高？我觉得对于view层，越是复杂，就越应该把structure, presentation, behavior三者分离。

复杂的东西都是客户“毛病多”最后搞出来的

我们做的东西页面巨简单，连复杂的js都没有 木哈哈哈，jsp+include servlet最合适

同意，我们的客户就是毛病巨多，挑三拣四，老板也强调要user experience，结果愣是从瘦客户端慢慢整成了富客户端。

对于简单的页面，简单是最好的设计。