|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-03-22
partech 写道 wch3116 写道 如果非要基于html＋javascript来实现一个离线应用的本地存储，可以在本地给远程域设置一个信任授权，通过js控制ADO操作本地的access或者file。实际上，我们在dao这一层（或service层）分别实现一个远程dao和本地dao，上层代码就可以不用去理会是在线还在离线的区别了。
dao或service层不都是在server端麽？离线了还能访问?不是很明白。 客户端的js同样可以分为这些层 |
| 返回顶楼 | |
|
发表时间：2006-03-22
我以为，在浏览器没有提供足够的内置支持之前，这样的方案一定得不偿失。
|
| 返回顶楼 | |
|
发表时间：2006-03-23
如果存本地文件，没有必要通过Browser了，就效率而言，单独开发离线客户端是更好的选择了。
存文件了，涉及到服务器数据更新不同步的问题，你一堆文件，他也一堆文件，最后分别上交数据时，涉及提交时机问题，同一条记录，最后交的覆盖前面的，最后交的不一定是最新的！ 我们可以从减小与服务器交互次数和交互数据量着手。高频访问的数据存于本地内存（js DAO）。让js找数据去！ (xml ) 注意定时让session不过期。 |
| 返回顶楼 | |
|
发表时间：2006-03-24
我认为Browser端存储有必要，但是应该是基于JS对象的key-value map的轻量级存储，如果引入SQL级的。。。有这个必要么？
|
| 返回顶楼 | |
|
发表时间：2006-04-05
我也有类似的Browser端存储，不过使用的是dojo.storage,也是用flash作为存储。但我也认为应该是基于JS对象的key-value map的轻量级存储，如果将sql都存储在客户端，也太危险了吧，整个将数据库结构都暴露出来了。
|
| 返回顶楼 | |
|
发表时间：2006-04-09
liuwangxia 写道 实际情况是，做一个 B/S 的连锁超市 POS 销售前端，数据库在总部，商品调价在总部。如果每扫描一次商品条码就从总部读一次，效率很低(主要是实际的网络情况造成的)，所以需要一个 Browser 端的缓存方案，来缓存商品信息，每次扫描商品条码只需要从 Browser 里读取数据即可，另外定时从总部更新的商品数据(仅仅获取需要更新的部分，不是重读整张表)。当网络意外中断时，也可以继续销售。TrimQuery 只是一种查询方案，XQuery 应该也是查询方案吧，但是仅仅有查询方案不够，还需要 Browser 端的存储方案，当Browser 关闭后再打开时即使脱机仍然有数据进行工作。Browser 可以缓存网页、图片、JS 脚本，不知道有没有缓存数据的功能？(有人会说可以用 XML页面来缓存数据，但是怎么能够实现每次从总部只获取需要更新的部分，而且保持浏览器重新打开时又有效呢？) 又联想到一个问题，比如 Gmail 和 Writely，虽然他们有定时保存的功能，但前提是必须在线，脱机的情况下是无法保存的。 如果要实现脱机的情况下数据存储，还得依靠 Flash 等插件，或者 Java Web Start 等等，单单依靠 Browser 和 Javascript 目前似乎还不行。 这个问题可以用其它方法解决. 不需要browser端存储. 采用分布式文件系统就可以解决 |
| 返回顶楼 | |
|
发表时间：2006-04-09
liuwangxia 写道 实际情况是，做一个 B/S 的连锁超市 POS 销售前端，数据库在总部，商品调价在总部。如果每扫描一次商品条码就从总部读一次，效率很低(主要是实际的网络情况造成的)，所以需要一个 Browser 端的缓存方案，来缓存商品信息，每次扫描商品条码只需要从 Browser 里读取数据即可，另外定时从总部更新的商品数据(仅仅获取需要更新的部分，不是重读整张表)。当网络意外中断时，也可以继续销售。TrimQuery 只是一种查询方案，XQuery 应该也是查询方案吧，但是仅仅有查询方案不够，还需要 Browser 端的存储方案，当Browser 关闭后再打开时即使脱机仍然有数据进行工作。Browser 可以缓存网页、图片、JS 脚本，不知道有没有缓存数据的功能？(有人会说可以用 XML页面来缓存数据，但是怎么能够实现每次从总部只获取需要更新的部分，而且保持浏览器重新打开时又有效呢？) 这样的应用为什么不使用C/S架构呢？觉得非常奇怪。 对于这样的应用，我的思路是使用Delphi或者VB做一个C/S终端管理程序，连接本地数据库。中心建立一个数据中心。客户端定期上传/下载数据到中心，可以使用xml-rpc、Soap实现。在我看来，这样的方案比较稳健，而且比较程序，相对来说对开发人员要求也不到。 如果使用javascript来作这样的应用风险比较大，ajax目前还是在发展初期，很多东西只是有个概念，而且真正能够将ajax在公司推广在我看来目前风险比较大的。 |
| 返回顶楼 | |
|
发表时间：2006-04-10
greateWei 写道 这样的应用为什么不使用C/S架构呢？觉得非常奇怪。
对于这样的应用，我的思路是使用Delphi或者VB做一个C/S终端管理程序，连接本地数据库。中心建立一个数据中心。客户端定期上传/下载数据到中心，可以使用xml-rpc、Soap实现。在我看来，这样的方案比较稳健，而且比较程序，相对来说对开发人员要求也不到。 如果使用javascript来作这样的应用风险比较大，ajax目前还是在发展初期，很多东西只是有个概念，而且真正能够将ajax在公司推广在我看来目前风险比较大的。 我觉得，风险在于开发团队对这种架构的了解和掌握程度，ajax本身不是新的技术，不存在什么风险。 至于C/S方案和B/S方案谁稳健，我觉得不能简单的下结论！你猜猜银行ATM终端系统，是C/S的还是B/S的？国内（大陆）的我不太清楚，但据中国台北的一位业内网友告诉我：中国台湾的ATM终端大多数都是Web系统。你在ATM机上看到的界面其实是HTML和Javascript (OS:nt4)。 这说明：不管是怎样的系统，只要应用规模大到一定程度，“标准”是最重要的，这也决定着风险系数。在“标准”这问题上，C/S是无法和B/S相提并论的。 |
| 返回顶楼 | |
|
发表时间：2006-05-13
好东东，正好需要！
多谢多谢啊！jsdb! |
| 返回顶楼 | |
|
发表时间：2006-05-17
wch3116 写道 greateWei 写道 这样的应用为什么不使用C/S架构呢？觉得非常奇怪。
对于这样的应用，我的思路是使用Delphi或者VB做一个C/S终端管理程序，连接本地数据库。中心建立一个数据中心。客户端定期上传/下载数据到中心，可以使用xml-rpc、Soap实现。在我看来，这样的方案比较稳健，而且比较程序，相对来说对开发人员要求也不到。 如果使用javascript来作这样的应用风险比较大，ajax目前还是在发展初期，很多东西只是有个概念，而且真正能够将ajax在公司推广在我看来目前风险比较大的。 我觉得，风险在于开发团队对这种架构的了解和掌握程度，ajax本身不是新的技术，不存在什么风险。 至于C/S方案和B/S方案谁稳健，我觉得不能简单的下结论！你猜猜银行ATM终端系统，是C/S的还是B/S的？国内（大陆）的我不太清楚，但据中国台北的一位业内网友告诉我：中国台湾的ATM终端大多数都是Web系统。你在ATM机上看到的界面其实是HTML和Javascript (OS:nt4)。 这说明：不管是怎样的系统，只要应用规模大到一定程度，“标准”是最重要的，这也决定着风险系数。在“标准”这问题上，C/S是无法和B/S相提并论的。 我所知道的大陆ATM系统都不是B/S实现的。目前来说，不大可能用B/S实现。 吐钞，点钞，打印这些设备控制控制可不简单哦。 JS的设备控制能力，运算能力够么？我不太能想象出台湾能用B/S实现？ |
| 返回顶楼 | |
