10 个解决方案
#1
那你有没有想过你的数据保存在什么地方，浏览器也不会自动把你把数据提交到服务器去的。
除非你用C/S模式的开发那样就可以的
除非你用C/S模式的开发那样就可以的
#2
c/s我就不问了。原来看google有个gear，后来google好像也不开发了。
#3
这个真有点难。
伪静态的页面是在本地有痕迹存在。
你可以试着用大量缓存（cache，viewstat）来测试，只能理论上可以。
伪静态的页面是在本地有痕迹存在。
你可以试着用大量缓存（cache，viewstat）来测试，只能理论上可以。
#4
你好像纠结这个好久了。
如果是自己想，那么忘掉吧。
如果是你的客户纠结，那么你想想客户是不是赖帐吧。
如果是自己想，那么忘掉吧。
如果是你的客户纠结，那么你想想客户是不是赖帐吧。
#5
实现这个,asp.net本身帮不了你什么,
仅仅是个最简单的html+js的静态站点部署到客户端就可以了,
或者干脆部署SL或者winform的客户端
#6
对于silverlight来说，它默认地有1M的客户端存储。你的程序可以声明扩展，例如使用500M客户端存储。这是一种可以取代cookied技术。客户端的silverlight程序不论是使用什么不同的浏览器，同一应用程序的客户端存储也是可以共享访问的，而不会像cookie一样各家浏览器互不共享。所以silverlight的客户端存储可以作为客户端本地持久化的数据库的基础，也有很多silverlight客户端数据库可以使用，例如我记得db4o好像就有silverlight客户端面向对象数据库。
不过这些都需要你复杂的逻辑设计。原本，应用程序在检测到网络临时中断时，就不要丢掉数据（例如不要清理当前的订单）也不要强行结束程序就行了。例如一个pos软件可以在数据上传到服务器之后才把发票的底部的付款、找零、银行信息等内容打印出来（之前可以一边扫描商品一边打印商品明细）。这就能够方便地看出维护程序，看出数据是否保存成功了。而没有必要搞什么客户端存储。
很少有必要再搞这个所谓的噱头设计。因为它有很多问题。除非你有非常非常充分的理由。
不过这些都需要你复杂的逻辑设计。原本，应用程序在检测到网络临时中断时，就不要丢掉数据（例如不要清理当前的订单）也不要强行结束程序就行了。例如一个pos软件可以在数据上传到服务器之后才把发票的底部的付款、找零、银行信息等内容打印出来（之前可以一边扫描商品一边打印商品明细）。这就能够方便地看出维护程序，看出数据是否保存成功了。而没有必要搞什么客户端存储。
很少有必要再搞这个所谓的噱头设计。因为它有很多问题。除非你有非常非常充分的理由。
#7
假设页面是asp.net程序加载的，当然也可以达到这类效果。因为只有加载需要asp.net，随后的整个交互过程就全都是通过javascript使用ajax方式与业务服务器通讯了。数据当然保存在浏览器端，并且也可以通过javascript存储在cookie。并且ajax通讯时你的程序当然也知道向服务器端保存数据是否成功。
（我怀疑你没有使用javascript做过应用程序，只做过简单的html页面）
问题是这样做的理由是否充分。如果是一个在校学生想搞噱头，是可以的。如果是企业应用，那么你应该首先想想使用html/javascript是否足以开发一个给企业里边的熟练操作用户使用的好的应用，首先想想你的程序的用户体验怎么样、是否强大，而不用过多考虑这类问题。
（我怀疑你没有使用javascript做过应用程序，只做过简单的html页面）
问题是这样做的理由是否充分。如果是一个在校学生想搞噱头，是可以的。如果是企业应用，那么你应该首先想想使用html/javascript是否足以开发一个给企业里边的熟练操作用户使用的好的应用，首先想想你的程序的用户体验怎么样、是否强大，而不用过多考虑这类问题。
#8
如果说asp.net程序离线了，理论上来讲你连这个网页都打不开了，请问你怎么保存数据？你连你自己建立的页面都看不到，我想问你的是，在打不开页面的情况下你能把数据保存在哪里呢？
除非说一种情况，就像7楼讲的那种，在使用过程中网络突然不能访问了，而你与后台的交互又是用ajax来实现的，这个时候提交异常的情况下你可以用js把你提交的数据保存成cookie或者别的格式，等网络通信正常了提示用户提交哪些未提交成功的数据。
除非说一种情况，就像7楼讲的那种，在使用过程中网络突然不能访问了，而你与后台的交互又是用ajax来实现的，这个时候提交异常的情况下你可以用js把你提交的数据保存成cookie或者别的格式，等网络通信正常了提示用户提交哪些未提交成功的数据。
#9
可以的，用HTML5.
#10
不可以
#1
那你有没有想过你的数据保存在什么地方，浏览器也不会自动把你把数据提交到服务器去的。
除非你用C/S模式的开发那样就可以的
除非你用C/S模式的开发那样就可以的
#2
c/s我就不问了。原来看google有个gear，后来google好像也不开发了。
#3
这个真有点难。
伪静态的页面是在本地有痕迹存在。
你可以试着用大量缓存（cache，viewstat）来测试，只能理论上可以。
伪静态的页面是在本地有痕迹存在。
你可以试着用大量缓存（cache，viewstat）来测试，只能理论上可以。
#4
你好像纠结这个好久了。
如果是自己想，那么忘掉吧。
如果是你的客户纠结，那么你想想客户是不是赖帐吧。
如果是自己想，那么忘掉吧。
如果是你的客户纠结，那么你想想客户是不是赖帐吧。
#5
实现这个,asp.net本身帮不了你什么,
仅仅是个最简单的html+js的静态站点部署到客户端就可以了,
或者干脆部署SL或者winform的客户端
#6
对于silverlight来说，它默认地有1M的客户端存储。你的程序可以声明扩展，例如使用500M客户端存储。这是一种可以取代cookied技术。客户端的silverlight程序不论是使用什么不同的浏览器，同一应用程序的客户端存储也是可以共享访问的，而不会像cookie一样各家浏览器互不共享。所以silverlight的客户端存储可以作为客户端本地持久化的数据库的基础，也有很多silverlight客户端数据库可以使用，例如我记得db4o好像就有silverlight客户端面向对象数据库。
不过这些都需要你复杂的逻辑设计。原本，应用程序在检测到网络临时中断时，就不要丢掉数据（例如不要清理当前的订单）也不要强行结束程序就行了。例如一个pos软件可以在数据上传到服务器之后才把发票的底部的付款、找零、银行信息等内容打印出来（之前可以一边扫描商品一边打印商品明细）。这就能够方便地看出维护程序，看出数据是否保存成功了。而没有必要搞什么客户端存储。
很少有必要再搞这个所谓的噱头设计。因为它有很多问题。除非你有非常非常充分的理由。
不过这些都需要你复杂的逻辑设计。原本，应用程序在检测到网络临时中断时，就不要丢掉数据（例如不要清理当前的订单）也不要强行结束程序就行了。例如一个pos软件可以在数据上传到服务器之后才把发票的底部的付款、找零、银行信息等内容打印出来（之前可以一边扫描商品一边打印商品明细）。这就能够方便地看出维护程序，看出数据是否保存成功了。而没有必要搞什么客户端存储。
很少有必要再搞这个所谓的噱头设计。因为它有很多问题。除非你有非常非常充分的理由。
#7
假设页面是asp.net程序加载的，当然也可以达到这类效果。因为只有加载需要asp.net，随后的整个交互过程就全都是通过javascript使用ajax方式与业务服务器通讯了。数据当然保存在浏览器端，并且也可以通过javascript存储在cookie。并且ajax通讯时你的程序当然也知道向服务器端保存数据是否成功。
（我怀疑你没有使用javascript做过应用程序，只做过简单的html页面）
问题是这样做的理由是否充分。如果是一个在校学生想搞噱头，是可以的。如果是企业应用，那么你应该首先想想使用html/javascript是否足以开发一个给企业里边的熟练操作用户使用的好的应用，首先想想你的程序的用户体验怎么样、是否强大，而不用过多考虑这类问题。
（我怀疑你没有使用javascript做过应用程序，只做过简单的html页面）
问题是这样做的理由是否充分。如果是一个在校学生想搞噱头，是可以的。如果是企业应用，那么你应该首先想想使用html/javascript是否足以开发一个给企业里边的熟练操作用户使用的好的应用，首先想想你的程序的用户体验怎么样、是否强大，而不用过多考虑这类问题。
#8
如果说asp.net程序离线了，理论上来讲你连这个网页都打不开了，请问你怎么保存数据？你连你自己建立的页面都看不到，我想问你的是，在打不开页面的情况下你能把数据保存在哪里呢？
除非说一种情况，就像7楼讲的那种，在使用过程中网络突然不能访问了，而你与后台的交互又是用ajax来实现的，这个时候提交异常的情况下你可以用js把你提交的数据保存成cookie或者别的格式，等网络通信正常了提示用户提交哪些未提交成功的数据。
除非说一种情况，就像7楼讲的那种，在使用过程中网络突然不能访问了，而你与后台的交互又是用ajax来实现的，这个时候提交异常的情况下你可以用js把你提交的数据保存成cookie或者别的格式，等网络通信正常了提示用户提交哪些未提交成功的数据。
#9
可以的，用HTML5.
#10
不可以