ASP.NET 自定义控件 - 回发的替代方案?

发布于 2024-07-04 03:57:54 字数 457 浏览 9 评论 0原文

在深入了解自定义 ASP.NET 控件开发过程中,我显然正在了解 ASP.NET PostBack 模型以及它如何影响控件开发。

据我所知,控件在 ASP.NET 中没有“生命周期”,因此必须在每次页面加载时重新初始化。 我们通过将对象值/参数保存到 ViewState 来克服这个问题。

因此,我读过的许多文章建议不要使用 PostBack,因为这会给页面增加相当大的开销。 我不是在寻找如何禁用它,我知道这一点。

我正在寻找的是:

除了使用 PostBack 模型来初始化控件之外,还有什么替代方案?

我知道我们可以使用 QueryString,但这看起来非常混乱,而且显然不可靠。

理想情况下,您可以向我概述不同方法的架构/设计及其优缺点。

非常感谢 ^_^

On my journey into the depths of custom ASP.NET control development I am obviously getting my head around the ASP.NET PostBack model and how it affects control development.

I understand that controls have no "lifetime" in ASP.NET, and therefore must be re-initialized on each and every page load. We overcome this by persisting the objects values/parameters to the ViewState.

Many articles I read therefore suggest not using PostBack since this can add considerable overhead to the Page. I am not looking for how to disable it, I know that.

What I am looking for is:

What alternatives to we have to using the PostBack model to initialize controls?

I know we could use the QueryString, but that seems awfully messy, and obviously unreliable.

Ideally you could give me an overview of the architecture/design of a different approach and the pro's/con's of it..

Many thanks ^_^

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

海夕 2024-07-11 03:57:55

嗯,Session State 是一个服务器端解决方案,如果您想完全避免使用 ViewState,那么它有自己的一堆麻烦事需要处理。 实际上,在自定义控件中使用 ViewState 是很好的 - 只是对您存储的内容挑剔 - 只存储声明的控件状态的增量,不要存储任何您将在回发中获得的内容(例如从数据库调用)等

Well, Session State is a server-side solution, with its own pile of cruft to deal with if you want to avoid ViewState altogether. Really though, using ViewState in a custom control is all fine and good - just be picky about what you store - only store deltas from the declared control state, don't store anything you're going to get on postback anyway (e.g. from a DB call), etc.

私藏温柔 2024-07-11 03:57:55

您必须将值存储在某处,因此您只能使用查询字符串和隐藏的表单字段。 如果将其与 HTTP 联系起来,基本上就是 GET 或 POST 参数。

我想你可以使用 cookies,但那样会很混乱。

You have to store the values somewhere, so you are limited to the query string and hidden form fields. If you relate that to HTTP, basically it's either GET or POST parameters.

I suppose you could use cookies, but that would be really messy.

忆离笙 2024-07-11 03:57:55
  1. 将对象状态存储在会话上下文中:这会将保存状态的负担从客户端转移到服务器,这对于小型 Intranet 应用程序来说可能是可以接受的。 对于首都互联网上的站点,这不起作用;

  2. 启用 AJAX 控制:在这种情况下,仅需要发回状态更改。 选择正确的框架是关键; 请参阅 http://www.asp.net/ajax/ajaxcontroltoolkit/samples/官方 MS 方法; 许多其他都是可能的。

  1. Store your object state in the session context: this will shift the burden of keeping state from the client to the server, which may be acceptable for small-scale intranet apps. For sites on the capital-I Internet, this won't work;

  2. AJAX-enable your control: in this case, only state changes need to be posted back. Picking the right framework is key here; see http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ for the official MS approach; many others are possible.

如果没有你 2024-07-11 03:57:55

如果您确实正在寻找 PostBack 模型的替代方案,那么我建议您研究 ASP.NET MVC 框架。 我很想把 WebForms 踢到路边,并在 MVC 中完成我所有的工作,但可惜的是,遗留代码是一个 tarbaby,重写几乎永远不是答案,所以我继续......

If you're truly looking for alternatives to the PostBack model altogether, then I would suggest researching the ASP.NET MVC Framework. I would love to kick WebForms to the curb and do all my stuff in MVC, but alas, legacy code is a tarbaby and rewriting is almost never the answer, so I plug onwards...

空宴 2024-07-11 03:57:55

我认为您仍然对控件有些误解。 仅当您将控件动态添加到页面时,控件才会出现您所描述的问题。 如果您在 aspx 代码中预先声明控件,那么它们将与页面一起构建。

I think you still mis-understand controls somewhat. Controls only have the problem you describe when you add them to the page dynamically. If you declare your controls upfront in the aspx code then they build along with the page.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文