【问题标题】:ASP.NET : How can i maintain objects between postbacks?ASP.NET:如何在回发之间维护对象?
【发布时间】:2010-11-29 17:13:04
【问题描述】:

如何在 ASP.NET 页面回发之间维护对象?

我有一个 ASP.NET 网页。当我单击一个 asp.net 按钮时,我将调用我的函数(Save),该函数将创建我的自定义类(UserDetails 类)的对象并将详细信息保存到 DB.so这是回帖。再次回帖后,将向用户显示相同的页面。那时,我想获取我在第一个函数(保存)中创建的用户对象。做这个的最好方式是什么 ?我知道我可以将其存储在 Session 中并访问它。但是我想知道是否有其他更好的方法?

【问题讨论】:

    标签: asp.net postback


    【解决方案1】:

    您可以将对象存储在 ViewState 中,这将是特定于页面的存储。然后该对象将被序列化并注入页面视图状态,这将使页面更大。

    通过将对象存储在会话中,可以使页面更小,但会消耗服务器内存资源。

    或者,您可以每次都从数据库中读取对象。这样做的好处是可以向用户准确地显示数据库中保存的内容。

    【讨论】:

      【解决方案2】:

      另一种选择是使用唯一键(例如“user”+ id)将对象存储在缓存中,并且仅将其 id 存储在当前会话或 ViewState 中。在回发期间,您可以从缓存中检索对象。

      使用这种方法,您有几个优势:

      • 您的会话或 ViewState 中的数据较少
      • 如果进行了回发,则仅当对象不再在缓存中时才需要访问数据库
      • 如果没有回发,对象最终会从缓存中移除(释放内存)

      【讨论】:

        【解决方案3】:

        在 UI 中执行此操作

            UserDetail userDetail = new UserDetail();
            //do your stuff
            userDetail = UserBL.TransferUserData(userDetail);
        
            //do your stuff
        

        在 BL 中

        public static UserDetail TransferUserData(UserDetail userDetail )
        {
            // do your processing on userDetail
            return UserDAL.TransferUserData(userDetail);
        }
        

        在 DAL 中

        public static UserDetail TransferUserData(UserDetail userDetail)
        {
        
            //do your processing of db
            return userDetail; 
        }
        

        【讨论】:

          【解决方案4】:

          您正在寻找的方法是某种数据绑定机制,它将对象的值(如果它已经存在,您可以从数据库加载)绑定到您的 asp.net 网络表单。

          基本上你会有以下:

          1. 您显示一个空的网络表单,其中包含对象属性的字段(即文本框)
          2. 用户将填写表格并按保存
          3. 然后将进行回发。在 PageLoad 上,您可以使用 Page.IsPostback 检测这是否是回发,如果是,则创建一个新对象并用用户输入的值填充它。
          4. 在按钮的 OnClick 中,调用适当的 BL 方法将其存储到 DB 中

          这看起来像(我是在没有编译器的情况下写出来的,所以要小心:))

          public partial class MyPage : Page
          {
          
              private Person myPersonObj;
          
              protected void Page_Load(...)
              {
          
                  if(!Page.IsPostback)
                  {
                      //this is not a postback, so you may load an object based on an ID (i.e. in QueryString or create a new one
                      myPersonObj = new Person();
                  }
                  else
                  {
                      //it is a postback, so unbind the values
                      myPersonObj = new Person();
                      Unbind(); //the myPersonObj will be filled, the values are managed by ASP.net in the ViewState
                  }
          
              }
          
              //caution, overriding Page.DataBind()
              private override void DataBind()
              {
                  textBoxFirstname.Text = myPersonObj.FirstName;
                  ...
          
              }
          
              private void Unbind()
              {
                  myPersonObj.FirstName = textBoxFirstname.Text;
              }
          
              protected void btnSubmit_OnClick(...)
              {
                  if(Page.IsValid)
                  {
                      Save();
                  }
              }
          
              private void Save()
              {
                   //ideal layering with Interfaces
                   IPersonBL personBL = MyBLFactory.Get<IPersonBL>();
                   personBL.SavePerson(myPersonObj); //call the BL for further validation and then persisting
              }
          }
          

          昨天想补充的,赶时间忘记了:
          您也可以像其他人描述的那样将您的对象存储在 ViewState 或 Session 中,但我已经体验到,由于以下“缺点”(从我的角度来看),它应该尽可能少地完成:

          • 您的对象需要可序列化
          • 在 ViewState 中存储会显着增加页面的大小,从而减慢页面的加载速度。请注意,每次“回发”发生时,ViewState 都会传输到客户端并返回。如果这是唯一的可能性并且您遇到性能问题,您可以考虑trying this(但这应该是例外!)
          • 在会话中存储对象可能会将负载放在服务器端,从而消耗那里的内存。您应该小心在会话中存储对象,并且如果您知道不再需要这些对象,还可能要注意销毁这些对象。

          我描述的“数据绑定”方法的优点是您没有这些问题,但每次都有一个新对象的“缺点”。因此,您必须注意处理您的对象状态,即通过往返等手动保持 id。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 2011-04-12
            • 1970-01-01
            • 2023-03-04
            • 1970-01-01
            • 2010-09-21
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多