|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (7) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-05-31
听说dwr --> 学习dwr --> 喜欢dwr --> 使用dwr --> 不喜欢dwr --> 放弃dwr
这样一条轨迹可以证明一个人技术水平的提高 |
| 返回顶楼 | |
|
最后更新时间：2008-05-31
我一接触dwr就不很喜欢dwr！虽然他表面看起来很帅
|
| 返回顶楼 | |
|
最后更新时间：2008-05-31
fins 写道 我接触dwr还算比较早
刚接触的时候确实被它小小的震撼了一下 但是后来 慢慢的觉得 这东西真的没啥必要. 建议楼主能够把现有的应用好好梳理一下 看看能否不使用dwr. 当然 也许现在这个应用已经不允许抛弃dwr了 不过 我还是希望你下一个应用能够少使用它. 理由: 一个ajax框架(纯js实现) + json/xml转换器(就是把javabean转换成json或xml的工具) + 以数据为中心的思想 完全可以很好的代替dwr 前一阵我写过一些对 JSF不屑的东西 但是 说实话 我觉得 dwr走的路在 JSF 和"以数据为中心的B/S系统" 中间 导致的结果是 "同时具备了两者的缺点和优点, 但是显然缺点要大大多余优点" 同意fins。我一直用的是json插件和mootools结合的路子。 楼主的问题估计是，你many-to-one的一端用了select绑定，改为join试试，修改hbm文件。 |
| 返回顶楼 | |
|
最后更新时间：2008-06-01
尝试一下buffalo如何呢？ 感觉buffalo+EXT2.0 应该是个很不错的组合。。。
|
| 返回顶楼 | |
|
最后更新时间：2008-06-01
icewubin 写道 从工作量上来讲，表面上看DWR能够节省服务端和客户端转换的工作量，但是服务端不做任何调整就能直接调的么？多半是不行的。当你使用Hibernate的时候，你的返回结果是要提前确定数据抓取的深度和力度，DWR的配置文件貌似没有这种灵活度的。再加上其他一些原因，导致服务端一般是很有必要有一层facade来处理和屏蔽一些东西，本来想节省web层的代码，几乎就被抵消了。 深度和粒度可以用hibernate的select new list (or map)方式来解决，volking的问题更多是没有把hibernate用好，而不是dwr的问题。 |
| 返回顶楼 | |
|
最后更新时间：2008-06-02
Readonly 写道 icewubin 写道 从工作量上来讲，表面上看DWR能够节省服务端和客户端转换的工作量，但是服务端不做任何调整就能直接调的么？多半是不行的。当你使用Hibernate的时候，你的返回结果是要提前确定数据抓取的深度和力度，DWR的配置文件貌似没有这种灵活度的。再加上其他一些原因，导致服务端一般是很有必要有一层facade来处理和屏蔽一些东西，本来想节省web层的代码，几乎就被抵消了。 深度和粒度可以用hibernate的select new list (or map)方式来解决，volking的问题更多是没有把hibernate用好，而不是dwr的问题。 深度和粒度原本不只是Hibernate的问题，但是因为过于“智能”，使得没有完全掌握它的人会出现使用不当，如果一个人很精通当然是不会有这一层面的性能问题。 但是进一步说，我是反对完全依赖hibernate的特性来改造某一个页面取数据的性能的，很容易使某一hibernate特性是专门针对一个页面应用优化的，虽说hibernate灵活性很好，但是还是要精简hibernate的使用情况（说得有些晦涩，比如级联的使用我就是反对的）。 话题转回来，同样一个hibernate配置，针对不同的页面取数据的需求，深度和力度不一致，这是我想说的，应该在抓取数据层面上多做文章，增加灵活性，当你有一个比较灵活的数据抓取工具后，开发效率要比每次去修改hibernate增加特性要方便得多，结构也更清楚。 说到抓取，不管是DWR还是其他什么JSON转换工具，你用默认的转换方式，多半是会自动遍历对象的所有属性，你如果用hibernate的技巧来应付这些工具的缺陷，工作量其实是不小的，而且前面说了因为不同场合，深度和力度还不一致，修改hibernate配置是容易很导致其他地方出现问题的。 这些是我在开发中的实际体会，首先强调hibernate确实是个很强大的工具，但是当我越了解他的强大，我发现我依赖它的地方反而越少，突然想到一句话，它的很多思想非常有借鉴意义。之前也在JavaEye上了解到有些人在转换JSON的时候用每个model的toJSON方法，有些是toString方法，但是都有不通用的问题，所以给大家一个思路，我认为在hibernate这层做文章是不适合的。 还想往下说：之前不是说DWR本身有问题，而是说，在数据抓取这一课题上，它也没什么灵活性可言，这一关键不能节省，会导致用DWR的意义大大降低，如此而已。 再继续：整个客户端和服务端的通讯如果以数据为中心的思想的话，加上整个系统大缓存策略（取了个怪名字，没想好，主要意思是指不用Hibernate的二级缓存，但是又想通过一些通用的非集群的需求来缓存相当一部分可以缓存的数据），服务端的提供数据层面（不属于任何层，是JVM级的）是可以大做文章的，务实点，可以从数据字典缓存开始着手，而且不必依赖hibernate的，因为即使使用hibernate的缓存，我认为在单独控制诸如数据字典这种简单结构上来说，hibernate的整个数据抓取机制是不够统筹（例：数据字典因为其稳定性，可以每5分钟到24小时，只用一句sql就能取出所有数据）的。 |
| 返回顶楼 | |
|
最后更新时间：2008-06-02
别的也许还凑合，之所以抛弃dwr是因为浏览器的兼容性有问题。
某些客户端浏览器xmlhttpRequest存在问题，虽然框架内部号称会自动转化为iframe，但是事实不是那么一回事。 不得已，写了一些违心的兼容代码。因为其不开源，写的时候调试也很痛苦，基本靠猜。 |
| 返回顶楼 | |
|
最后更新时间：2008-06-02
我想问一句
使用其他的ajax 就能在view 中open session 就不需要 数据之间的转化么 |
| 返回顶楼 | |
|
最后更新时间：2008-06-02
lzmhehe 写道 我想问一句
使用其他的ajax 就能在view 中open session 就不需要 数据之间的转化么 当然是都要转化的，用了hibernate，转化的过程一般也就是数据抓取的过程。但是好像这里很少有人详细讨论这个“复杂”的转换话题。 我是觉的DWR带来的好处实际上是不太多的，fins的当初分析DWR的问题对我影响比较大，我再从其他方面进一步说明DWR不能解决的问题和类似于其他服务端生成JS框架的通病。 简单总结： 很多入门时间不长的人，认为DWR能够直接调用服务端的java程序，屏蔽了很多复杂度。 带来的问题： 1.DWR就是一个ajax过程，整个过程并不都是在服务端的view概念中的。要用好DWR就要对他机制非常清楚。 2.DWR实现的过程用其他框架组合来做也不复杂，有更好的灵活性。 3.楼主碰到的性能问题还没确定问题所在，DWR配置不当造成数据转化过多（导致数据抓取过多）是有这个可能的。 4.调试周期长是服务端生成JS框架的通病。 5.凡是有Java基础的，再学Javascript是很快的，我可以告诉还未学习的人，学习Javascript不会耗费太多时间，而且不会白学的，其中不少概念吃透了就是自己的了。 |
| 返回顶楼 | |
|
最后更新时间：2008-06-02
volking 写道 ssh+dwr
1 只能返回基本类型的数据，例如string ,date，如果是对象类型，则会说no session，很明显session已经关闭了，试着在OpenSessionInViewFilter里配了一下，可以用，问题是控制台会运行N多个select语句。不知什么原因。 2 放弃上面的办法，只能select new来，郁闷的是要给pojo添加字段，例如给每个外键添加String类型，还要写一个很长的构造函数。唉～～。晕那。 有一个select效率的疑问： 链接查询效率高还是分2条查询效率高？ 上面1的方法，只运行一条select语句，但是有3个表的链接。 3个表的链接查询也可以分成3条select语句来实现。 这2种查询，差别会有多大了？我感觉是差不多。 1,你配置的hibernate lazy=true,假如你获得对象的关联对象.肯定会多SELECT语句. 2,如果不是超大型访问量的网站.还是用OpenSessionInViewFilter来处理. 3,是N+1还是N+M条SQL语句的问题.搜一下吧.有很多这样的讨论. BTW.你先把局部页面利用类似模板的形式处理好.然后直接返回一个string.多精神? velocity当中可以利用Template和Data来merge页面. 不知道struts有没有类似的功能?我想也应该有吧 |
| 返回顶楼 | |
