|
锁定老帖子 主题：MVC中被忽略的View层
精华帖 (1) :: 良好帖 (0) :: 新手帖 (3) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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不懂，那不利于协同工作。除非从前台到后台都是由你一个人来完成。 日后维护也是一个问题。 |
| 返回顶楼 | |
|
发表时间：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丫 |
| 返回顶楼 | |
|
发表时间：2009-09-22
iaimstar 写道 要解决这些问题，我期望的View层能够： ＊很好的分离逻辑与显示，不是宣称，而是真正解决问题，不过还没想好是什么样子 ＊动态内容和静态内容很好的分离，静态的资源有很好的抽象和管理 ＊简单直白的开发维护方式 iaimstar 写道 前面说了，东西巨简单，简单到没必要有UI存在的地步，何况 我就是我们公司的美工～～，精通phtoshop丫 页面上的东西有两种：
样子用 HTML/CSS 写， 逻辑用 JS 写。 构建任何界面元素都可这样来划分。 数据来源也有两种:
根据不同的需求，可以决定某一个界面的数据如何产生，一般的网站主要采用1，结合2。便于SEO。 B/S软件适合 2， 可以让开发更加简化。 在这两个思路基础上，在不同的项目中总结一套自己的 UI 解决方案并不是太难的事情。 |
| 返回顶楼 | |
|
发表时间：2009-09-22
zozoh 写道 iaimstar 写道 要解决这些问题，我期望的View层能够： ＊很好的分离逻辑与显示，不是宣称，而是真正解决问题，不过还没想好是什么样子 ＊动态内容和静态内容很好的分离，静态的资源有很好的抽象和管理 ＊简单直白的开发维护方式 上面这个这不是我写的。。。 iaimstar 写道 前面说了，东西巨简单，简单到没必要有UI存在的地步，何况 我就是我们公司的美工～～，精通phtoshop丫 页面上的东西有两种：
样子用 HTML/CSS 写， 逻辑用 JS 写。 构建任何界面元素都可这样来划分。 程序员一直在尽量避免把业务逻辑写到页面上，即使是js里面，客户操作流程无所谓 数据来源也有两种:
根据不同的需求，可以决定某一个界面的数据如何产生，一般的网站主要采用1，结合2。便于SEO。 B/S软件适合 2， 可以让开发更加简化。 在这两个思路基础上，在不同的项目中总结一套自己的 UI 解决方案并不是太难的事情。 我自己也有UI解决方案，用servlet也是有理由的，就像前面说的项目页面非常简单，jsp＋include servlet足够了，我没有必要为了一个1个星期需求简单的小玩意整合一个所谓UI组件进去，徒增复杂度，这种情况，程序员看代码更容易清晰 |
| 返回顶楼 | |
|
发表时间：2009-09-22
能简洁当然好，尽量使页面简单化，但不要太简单！View层现在的解决方案很多，动态和静态部分的耦合度大小可以取决于项目需求 .
|
| 返回顶楼 | |
|
发表时间：2009-09-22
argan 写道
现在市面上这么多的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个工作日，还得申请紧急发布（得老大批准） >>如果“动态”页面涉及复杂的业务逻辑、数据库操作，而这些后台的复杂操作只输出一个很简单的结果，你（或老板）只看到这是一个很简单的东西（结果），当然就对需要1工作日的工作量不能理解了。 ＊开发人员说：UED的同学怎么又把模板里的一个变量给搞掉了，内容又不正确了（甚至是页面500了） >>呵呵，这个。。。废话嘛，没了一个变量，除非它本来就未被程序使用，否则要是程序依然可以正常工作，那叫灵异事件。 ＊法务说：有个推广链接要拿掉，全给我找出来干掉！不然老板要被请去喝咖啡了。 >>嗯，这个嘛，仔细的设计你的模板，恰当的使用include技巧，可以不用修改全部页面，只要修改被include的块就解决了，但总有人轻视include原则的。
要解决这些问题，我期望的View层能够： ＊很好的分离逻辑与显示，不是宣称，而是真正解决问题，不过还没想好是什么样子 >>不知道你在说什么，这个是View层提供的功能？还是设计、编码人员大脑中应该时刻遵循的原则？我想至少jsp和jstl早就提供了工具分离逻辑和显示了，但如果你们一定要在jsp中写scriptlet，也没有人拦得住你的。所以，还是大脑中的规则比较重要吧。 ＊动态内容和静态内容很好的分离，静态的资源有很好的抽象和管理 >>没有看懂，你对“很好的抽象和管理”的定义是什么？ ＊简单直白的开发维护方式 >>呵呵，我曾经有一个同事，那时是在2000年，他是我们销售总监的同学。他来到我们公司，一开始的愿望是做一个程序员，他说：“你看，我这样……再这样……，拖拉几个输入框、下拉列表框，图形背景……，你看，这个‘程序’就可以运行了，很简单的，而且很漂亮。做程序员真是太酷了……”。当然，2周以后，他还是去做销售了……
好吧，关于最后的那个同事的故事，大家不要对号入座，开个玩笑的 |
| 返回顶楼 | |
|
发表时间：2009-09-22
jansel 写道 UI层本身变化很大，所以UI要形成一个通用的很难。通过看各个框架提供的Tag就知道了，只能处理数据，布局是很难搞的。
所以只要有Tag，那么肯定会和HTML Tag混合起来用，这样维护就成问题了。 个人还是喜欢Wicket的简介的方式，UI就交给HTML了。 wicket和tapestry处理方式非常类似，也是我看到的相当优雅的一种方式了，这基本能解决模板的问题了 不过我考虑的还有其他静态资源的管理问题，比如js，css，图片资源，这些都需要在我们的模板里面去引用，如果要修改一个js/css/image，我必须检查所有可能引用的地方，否则也不敢乱动 据ebay的一些文档描述的样子看来，他的V4已经能很好的管理这些资源了，不过看起来很复杂，可以参考 http://www.ibm.com/developerworks/cn/opensource/os-eclipse-ebay1/ 还有 http://yiminghe.iteye.com/blog/427337 且不说他的解决方案如何，至少要解决的问题是类似的，这个问题困扰了我很久，一直没有很好的方案 我期望的最终目标是将展示*完全*交给UED部门和运营部门，开发不用关心，开发和UED之间只有一种约定，或者定义一种自己特有的DSL，供UED来使用，这个DSL不是模板，是业务的一些标签，或者标记 供yy，也表达一下我本来的意思 |
| 返回顶楼 | |
|
发表时间：2009-09-22
＊运营人员说：要修改一个链接和一段文本，因为在一个动态页面里面，需要开发人员来动手，于是在某个应用上（或几个）做分支，修改，测试，预发布，发布 靠，我就改这么点东西，告诉我需要1个工作日，还得申请紧急发布（得老大批准） >>如果“动态”页面涉及复杂的业务逻辑、数据库操作，而这些后台的复杂操作只输出一个很简单的结果，你（或老板）只看到这是一个很简单的东西（结果），当然就对需要1工作日的工作量不能理解了。
>> 我是站在开发这个角度来看的，这里只是说明由开发人员去维护这些页面的别扭，虽然这里描述的流程是复杂了点（真实的流程），是可以删减，但是问题重点不在流程，也不在具体开发什么内容
＊开发人员说：UED的同学怎么又把模板里的一个变量给搞掉了，内容又不正确了（甚至是页面500了） >>呵呵，这个。。。废话嘛，没了一个变量，除非它本来就未被程序使用，否则要是程序依然可以正常工作，那叫灵异事件。
>> 同样的，这里要说明的也只是UED的同学去动这些有程序逻辑／变量的模板的苦难所在
＊法务说：有个推广链接要拿掉，全给我找出来干掉！不然老板要被请去喝咖啡了。 >>嗯，这个嘛，仔细的设计你的模板，恰当的使用include技巧，可以不用修改全部页面，只要修改被include的块就解决了，但总有人轻视include原则的。
>> 你永远不知道哪些东西需要预先用include的方式处理，事先能想到的头啊尾啊，常见的公用地方都已经类似处理过了，这里只是说明现在的方式处理一些突发的事件很繁琐，不过这个提法本身可能就有些问题，又想不事先知道，又想随时想改就改，呵呵，我太贪婪了
要解决这些问题，我期望的View层能够： ＊很好的分离逻辑与显示，不是宣称，而是真正解决问题，不过还没想好是什么样子 >>不知道你在说什么，这个是View层提供的功能？还是设计、编码人员大脑中应该时刻遵循的原则？我想至少jsp和jstl早就提供了工具分离逻辑和显示了，但如果你们一定要在jsp中写scriptlet，也没有人拦得住你的。所以，还是大脑中的规则比较重要吧。
>>看来没看明白我前面描述的问题，我没觉得jsp/jstl分离的有多好
＊动态内容和静态内容很好的分离，静态的资源有很好的抽象和管理 >>没有看懂，你对“很好的抽象和管理”的定义是什么？
>> 结合前面的运营人员和法务的案例去推测吧，挺难描述的
|
| 返回顶楼 | |
|
发表时间：2009-09-22
argan 写道
要解决这些问题，我期望的View层能够： ＊很好的分离逻辑与显示，不是宣称，而是真正解决问题，不过还没想好是什么样子
我也一直想知道真正解决问题的方案是什么 jsp吧，标签很方便，但是有种说不出的别扭 不用标签吧，代码可能看了会吐。
或许能指望html提供一种基于新的html标准标签的解决方案，提供一种标准数据格式规范和处理方案，比如xml或者json
亦或者我们放弃浏览器，甚至更新成浏览器 2.0，支持新的标准和开发方式
算了，直接页面里嵌个flash。。比啥都强 |
| 返回顶楼 | |
|
发表时间：2009-09-23
>> 你永远不知道哪些东西需要预先用include的方式处理
??? 所有的都“预先知道”是不可能的，但是当同样的内容被复制、粘帖了2次以上还不知道的话，就没什么好说的了 |
| 返回顶楼 | |
