我应该在 Page 对象的哪里实现功能 - 构造函数还是 OnPreInit？
我已经思考了一段时间的一个问题 - Stackoverflow 用户通常会在构造函数中实现重要的功能（特别是在从 System.Web.UI.Page 类派生的类中），还是我们应该让这里的逻辑尽可能简单并且而是在 OnPreInit 中实现功能（使用构造函数简单地实例化页面其余部分中的功能所需的对象/值）？ 对于这种情况是否有“最佳实践”方法？
这个问题的背景：
我正在开发的系统有一个相当深的页面层次结构 - 实际页面派生自大约 10 个链式页面对象：
-- System.Web.UI.Page ----- CustomPage1 : System.Web.UI.Page -------- CustomPage2 : CustomPage1 ---------- etc
每个页面添加一个特定的功能，并且通常存在依赖关系在自定义页面构造函数内运行的代码，或者功能本身在构造期间直接运行。
最能说明我的问题的示例是将自定义对象从我们的数据库加载到页面的页面，以便它们在页面生命周期内可用 - 在页面构建期间与数据库建立连接，然后使用正确的值填充公共属性。
在我看来，这最好通过 OnPreInit 事件来完成，主要是因为在运行父逻辑之前我们可以更灵活地执行一些页面级别的检查（例如，我们是否希望阻止调用此功能）（假设在构造函数中的顺序执行将在子类之前构造父类）。 从面向对象的角度来看，OnPreInit 似乎是实现此功能的更合适的区域 - 页面构造应该处理页面的构造、设置任何默认值等，然后 OnPreInit 将用于执行在该过程中所需的任何功能。页面的生命周期。
A question I have been thinking about for a while - would Stackoverflow users commonly implement significant functionality in a constructor (specifically in classes derived from the System.Web.UI.Page class) , or should we keep the logic here as simple as possible and instead implement functionality in OnPreInit (using the constructor to simply instantiate objects/values that are required for the functionality in the rest of the page to function)? Is there a "best-practice" approach to this scenario?
The background to this question:
The system that I am working on has a fairly deep page hierarchy - there are about 10 chained page objects that the actual page derives from:
-- System.Web.UI.Page ----- CustomPage1 : System.Web.UI.Page -------- CustomPage2 : CustomPage1 ---------- etc
Each page adds a specific piece of functionality, and often there is either a dependancy on code run within the custom page constructor, or the functionality itself is directly run during construction.
The example that best illustrates my question is the page that loads custom objects from our database to the page so they are available during the page lifecycle - during page construction connections are made to the database and then public properties are populated with the correct values.
To my mind this is better done from the OnPreInit event, mainly because we have greater flexibility to perform some page level checks (e.g. should we want to prevent this functionality being called) before the parent logic is run (given that in a constructor the order of execution will construct the parent classes before the child class). From an OO perspective as well OnPreInit seems to be a more appropriate area to implement this functionality - page construction should deal with construction of the page, setting any default values, etc and then OnPreInit would be used to perform any functionality that was required during the lifecycle of the page.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为你的推理非常合理 - 我同意
OnPreInit是这种逻辑的正确位置。I think your reasoning is very sound - I agree that
OnPreInitis the proper place for such logic.根据实际功能，我建议使用 OnInit 或 OnLoad 而不是 OnPreInit。 引入 OnPreInit 是为了支持动态设置主题或母版页，这是您在生命周期后期无法执行的操作。
Depending on the actual functionality I would suggest using OnInit or OnLoad instead of OnPreInit. OnPreInit was introduced to support setting the theme or master page dynamically, what you cannot do later in the lifecycle.
请记住，如果是回发，则控件值尚未从 ViewState OnPreInit 恢复。
MSDN 给出了事件使用建议。 请参阅“生命周期事件”。 示例：
Keep in mind that control values have not been restored from ViewState OnPreInit if it's a postback.
MSDN gives suggestions for event use. See "Life-Cycle Events". Examples: