锁定老帖子 主题:MVC中被忽略的View层
精华帖 (1) :: 良好帖 (0) :: 新手帖 (3) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-09-21
iaimstar 写道 我还是比较喜欢servlet直接print代码
遇上复杂的ui,这么print岂不是耦合度太高?我觉得对于view层,越是复杂,就越应该把structure, presentation, behavior三者分离。 |
|
返回顶楼 | |
发表时间:2009-09-21
prowl 写道 tapestry才是最完美的view OOP。
楼主列的那些问题 完全可以再tapestry里轻松解决。 tapestry 是做了不少的事情,解决方案也挺干净的,但还是不够理想,可能我想的不仅仅是一个模板的问题了吧,实际上涉及到的不止是开发这个环节的问题 |
|
返回顶楼 | |
发表时间:2009-09-21
logicgate 写道 iaimstar 写道 我还是比较喜欢servlet直接print代码
遇上复杂的ui,这么print岂不是耦合度太高?我觉得对于view层,越是复杂,就越应该把structure, presentation, behavior三者分离。 复杂的东西都是客户“毛病多”最后搞出来的 我们做的东西页面巨简单,连复杂的js都没有 木哈哈哈,jsp+include servlet最合适 |
|
返回顶楼 | |
发表时间:2009-09-21
iaimstar 写道 logicgate 写道 iaimstar 写道 我还是比较喜欢servlet直接print代码
遇上复杂的ui,这么print岂不是耦合度太高?我觉得对于view层,越是复杂,就越应该把structure, presentation, behavior三者分离。 复杂的东西都是客户“毛病多”最后搞出来的 我们做的东西页面巨简单,连复杂的js都没有 木哈哈哈,jsp+include servlet最合适 同意,我们的客户就是毛病巨多,挑三拣四,老板也强调要user experience,结果愣是从瘦客户端慢慢整成了富客户端。 对于简单的页面,简单是最好的设计。 |
|
返回顶楼 | |
发表时间:2009-09-21
logicgate 写道 iaimstar 写道 logicgate 写道 iaimstar 写道 我还是比较喜欢servlet直接print代码
遇上复杂的ui,这么print岂不是耦合度太高?我觉得对于view层,越是复杂,就越应该把structure, presentation, behavior三者分离。 复杂的东西都是客户“毛病多”最后搞出来的 我们做的东西页面巨简单,连复杂的js都没有 木哈哈哈,jsp+include servlet最合适 同意,我们的客户就是毛病巨多,挑三拣四,老板也强调要user experience,结果愣是从瘦客户端慢慢整成了富客户端。 对于简单的页面,简单是最好的设计。 支持简洁之上 |
|
返回顶楼 | |
发表时间:2009-09-21
世间万物,
越靠近人, 就越复杂越难把握; 越远离人, 就越简洁越易掌控. |
|
返回顶楼 | |
发表时间:2009-09-21
wanglei8 写道 logicgate 写道 对于简单的页面,简单是最好的设计。 支持简洁之上 盲目推崇简单至上是不实际的。简洁至上的前提是你的设计必须能满足系统绝大部分的需求(包括客户的需求)。我觉得我很多时候都是在确保系统不过分复杂以至于降低开发效率和满足用户体验两者之间挣扎。 ![]() |
|
返回顶楼 | |
发表时间:2009-09-21
抛出异常的爱 写道 wiki丰富化
就是页面的所有元素 都是用wiki可调的. 这样子业务人员才能真正的自己完成业务逻辑 PS:如果自己写html生成模板...我就用决对定位来布局元素. Wiki丰富化是指?异常哥可否说的详尽一些,或给点例子 |
|
返回顶楼 | |
发表时间:2009-09-21
很好的分离逻辑与显示,不是宣称,而是真正解决问题,不过还没想好是什么样子
没有想好,就表明view的确不好分 |
|
返回顶楼 | |
发表时间:2009-09-21
对于很多系统,view层是最容易被忽视被认为简单,但实际上非常具有挑战性,也非常容易导致混乱的一层。
几年前看ajax in action的时候,里面提到一种nested mvc,我觉得对于业务系统的复杂ui来说是一个不错的实践。 |
|
返回顶楼 | |