困惑多年，马上给分ASP.NET程序员必须解决的两个问题？

Question

1、DataGrid中能不能实现自动将数值返回DataSet。
  每次打开page,生成DataSet ds = new DataSet();将DataGrid的数据源指定ds。然后修改或删除任何的数据，需要重新将删除，新增，修改的结果写在ds 里面。一行一行的更新。我想要的是象WINFORM那样，只要DataGrid执行了任何操作，ds里面自动更新。然后将ds提交到数据库就OK了。
事实上是生成了ds以后，每次postback，ds被清空。
2、参数传递
页面之间除了用Response.Redirect("123.aspx?PrdtKind='&OrderType=tage'")传递字符串参数以外，还能不能用其他方式传递其他的参数呢？如传递DataSet或HashTable等。

Answer 1

1:可以，你不要每次刷新都重新绑定用!page.postback
可以在每个文本框中添加事件，发生数据改动后，立即在dataset中修改该条记录。
但个人不建议这样做。
2：可以传对象

Answer 2

楼主不要想多了，不要老将B/S与C/S比较，，老是在B/S中实现C/S的功效，，，，虽说C/S中有一些做法，很简单，但B/S毕竟不是C/S，，要搞清B/S的特点，，老究这些是没什么意义的。。

Answer 3

B/S主要是做浏览用的，在编辑方面不可能象C/S那样，如果只要修改就提交，那样会速度很慢

Answer 4

2、参数传递
页面之间除了用Response.Redirect("123.aspx?PrdtKind='&OrderType=tage'")传递字符串参数以外，还能不能用其他方式
++++++++++++++++++++++++++++通过Session，可以在两个页面间传递任何一种数据类型的。

Answer 5

最主要一点.B/S是无状态的...不能和C/S比.

Answer 6

其实个人觉得以后bs的发展发向也是利用客户端的资源尽量向有状态方向靠拢，象viewstate就是一种类型（虽然比较糟糕）

Answer 7

基本上asp.net的控件都不支持（与数据源的）双向绑定，只支持直接DataBind方法从数据源绑定到控件。WinForm的控件一般都支持双向绑定（它是高层抽象控件的机制，因此被底层所有控件继承），不过双向绑定需要在架构上增加很多抽象层次、有一定性能消耗。但是双向绑定并不是控件“必然”的。你看看那些被淘汰了过去很火的开发工具，很多非常牛的架构，可是因为在双向绑定等这些“小”问题上不坚持贯彻使用，结果被程序员慢慢遗忘了。微软的web环境，如果还有一些务实的架构师活者（而不是一些学者），我们可以相信会像WinForm一样方便的。对很多程序员来说，你不告诉他性能代价，它会说你的控件很牛很好用。一旦说了，他就以为是什么天大的BUG。我想除了时间仓促，这可能是最主要的暂时不提供与WinForm的双向绑定类似的绑定机制的原因。

Answer 8

楼上的，B/S结构要实现双向绑定，估计难度很大。如果仅仅在服务器端实现双向绑定，那就意义不大了，还不如手工提交算了。其实，问题在于，B/S结构的，没有在客户端实现数据缓存，数据缓存还是在服务器端。如果，在浏览器上做到了，缓存数据，并且一次性提交这样就比较好了。但是，这样的组件还没出现，如果要出现，估计客户端脚本和天书差不多了。

Answer 9

关于参数传递，给一个参考方法：string EID=System.Guid.NewGuid().ToString();
//在这里把你的参数集合写入名为params的ArrayList
this.Cache.Add(EID,params,null,Now.AddSeconds(20),..........);
Response.Redirect("123.aspx?pid="+EID);在123.aspx中直接从Cache中获取EID下标的ArrayList，其中就是各种参数。这样，过20秒钟内存就释放了。并且客户端从url上看不出参数的内容。

Answer 10

双向绑定并不复杂，何况这只要在webControl类中或者更高层实现，而不需要对其它底层控件去改写。本来我以为asp.net2.0就会具有这个功能，现在只能等将来了。现在asp.net控件被很多接受了web服务器控件人用错了方法，这与其过分简单有关（不得不作很多扩展），也为它充分实现微软的一贯的控件的风格造成了障碍。

Answer 11

如果在客户端实现，那么不就是c/s了？c/s与web的差别，不是因为不能够通过互联网安装那些自定义控件。早在差不多7、8年前，微软就有很多基于互联网的软件开发方法，例如VB5中就发明了完全将windows窗口全套元素搬上dhtml页面的非常完善的方法，类似的还有好几种，但是都失败了。我们可以期待胖客户端作为web的终极解决方案么？这是站在用户的角度，还是站在某些公司程序员的角度上？

Answer 12

如果IE不改，也不使用ActiveX，也不使用其他的可下载安装的控件，就靠，目前的客户端脚本，我看实现起来难。难。

Answer 13

我主要是基于程序撰写的速度来说的，确实按照ASPNET的情况，B/S开发的速度基本上只有C/S的1/3。

Answer 14

1.有需求就有解决的办法.
看你怎么实现了.
2.
<a href=""></a>
Server.Transfer();
Session,Application.
Cookie等．．．

Answer 15

客户端安装可下载的控件，就现在看来，是不太安全的。如果，进行.net的组件下载在客户端运行，或者应用程序下载运行，目前可以做到，就是安全性还得不到认可。除非，真的，.net实现了他宣传的那样的安全性。即便，如此，也不能排除恶意的网站损害客户。即便可控的资源很多，要一个普通用户设定IE下载的.net组件的可用资源范围那也是很困难的。用户肯定使用最简便的办法，就是开放全部资源，那样，安全性就太差了。胖客户端，适用范围还是很受限制的。HTML经过很多年的考验，基本上可以被接受是一种比较安全的客户端表现方式了，我看，要制定新标准，难。

Answer 16

传递参数,除了使用redirect之外,你还可以使用Transfer,具体请参见如下代码.
另外,如果要将第一次取出来的数据能保存在页面生命周期中使用,你可以使用cache作为保存的一个手段.
比如求取一个Datatable之后,利用cache保存
Cache["mytab"] = DataTable1;
之后,在页面提交之后,反向求取出刚才保存的值
DataTable mytab = (DataTable)Cache["mytab"];
如此,就达到了楼主想要的效果.
不过,这种方式,加大了内存的消耗.要传递值的页面asm_content_view.aspx
/// <summary>
/// 搜索值
/// </summary>
public string strText
{
　　get
　　{
　　　　return(this.txtsearch.Text);
　　}
}/// <summary>
/// 搜索类型
/// </summary>
public string strType
{
　　get
　　{
　　　　return(this.listsearch.SelectedValue);
　　}
}/// <summary>
/// 搜索
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void butsearch_Click(object sender, System.EventArgs e)
{
　　this.Server.Transfer("asm_content_list.aspx");
}
要接收的页面
//查看有无从asm_content_view页面转来的搜索对象
string strname = Context.Handler.ToString().ToLower();
if( strname == "asp.asm_content_view_aspx")
{
　　mydata.content.page.asm_content_view myform = new asm_content_view();　　　　　　　　
　　myform = (mydata.content.page.asm_content_view)Context.Handler;
　　this.txtsearch.Text = myform.strText;
　　this.listsearch.SelectedValue = myform.strType;
}