大家好。 我完全不同意ASP.NET事件处理模型。 这是我经过几周努力工作后得出的最终结论比MSPetShop更真实的网络应用程序;） 我坚信事件处理模型是繁琐，复杂，低效，而且，嗯，......不可预测！最后但并非最不重要的是，它与旧的ASP处理逻辑完全形成对比。 这是一个例子： - 在用户控件中放置一个下拉列表并填写它有一些项目。在SelectedIndexChanged事件上，只需将选定的值保存在Session变量中。 - 在几个Web表单中添加用户控件。 - 假设取决于值您希望在Web表单中显示不同结果的Session变量。 这是错误判断和误解的典型示例，尤其是对于从ASP迁移到ASP.NET的人员。 考虑事实： -每个Web表单的Load事件在用户控件的Load事件之前触发。 - 因此你无法真正说出什么'在你的Session var中... -...因为usercontrol将在web表单之后触发它的代码。 -网页表单必须...等待....对于用户控制...一切。 这只是其中一个案例。我相信Load事件通常在处理模型中的错误位置和时间处理。 IsPostBack只是防止地狱破裂的最后一分钟借口。 当然，我知道你们有些人说这种帖子是纯粹的讽刺，其他人可能会发现它太过于吵架甚至疯狂。 但请考虑在软件公司工作的程序员每天（而不是在家里只是为了测试和乐趣!!!）并且只是想让事情发挥作用。他们肯定不需要所有这些混乱。 dimitris
解决方案感谢您的意见，我必须说有很多其他网络技术可用，如果asp不是你喜欢的，没有人强迫asp扼杀你的喉咙。就个人而言，我从来没有遇到过这个事件模型的问题，你有没有想过你的设计是错误的？你有多长时间编程知道绝对没有其他方法可以做到这一点？如果我这样做，我的usercontrol将公开它自己的webform将处理的事件，并对表单进行适当的更改。在这种情况下，我认为没有必要使用会话变量。 - 迈克尔 " Dimitris Pantazopoulos" < Di ******************* @ discussion.microsoft>在消息新闻中写道：57 ********************************** @ microsof t ...
我不同意你，但我的意见来自完成旅行 通过沮丧的山谷，了解新的 模型。 我认为挫折是正常的部分方法论的变化过程。 大多数ASP开发人员，包括我自己，都试图在ASP.NET中制作类似ASP的页面。这种范式的混合使得它非常难。通常情况下，很容易转换语言语法来完成范式转换，而不是继续使用熟悉的语言。然后，您可以回到原来的语言。从VBScript ASP转到C＃，我做了这个 。我现在同时做C＃和VB .NET。 让我们检查一下： Page_Load - 用于设置页面当它加载。为了获得最佳效率并且最小化毛发拉动，这仅在首次加载时设置页面。如果你的 Page_Load超过几行，你很可能做错了。 坏的例子Page_Load： protected void Page_Load（object sender，EventArgs e） { if（！Page.IsPostBack） { //做了很多东西，检查了很多QueryString vars } else { //提交表格时做了很多不同的事情 } } 正确： protected void Page_Load（object sender，EventArgs e） { if（！Page.IsPostBack） { //只做初始状态所需的内容 } } protected void Button_Click（object sender，EventArgs e） { //这个按钮是什么时候需要这个页面 //点击。如果你在Page_Load中控制了一些回发 //将它移到另一个例程并从这里调用它而不是 //不要在Page_Load中运行任何回发代码除非它 //在每个回发上运行。如果它是有条件的，从这里运行 //重构你的代码以适应这个模型 } 控制控制控件： 你在这里有几个选择，每个都很痛苦： 1.通过客户端脚本运行 2在服务器端运行 对于小型列表，客户端是回传 模型的完美可行选项，因为它避免了访问服务器。这次旅行并不是很重，但是比设置一个短名单要重。但是，如果列表很长，客户端 脚本是一个庞大的解决方案。例如，选择一个国家，国家设置状态 列表。选择州，州设置城市或县名单。为了做到这一切，所有客户端 方面，你下载了MB的脚本，这使得该应用程序无法在极端宽带以外的任何物品中使用。服务器之旅是有序的。 一种方法： 我更喜欢从零开始建立一个页面。这来自于我对于b / b 不准确数据的偏执。将所有内容关闭为状态1，并根据 特定条件启用。如果用户必须先从一个列表中选择，只显示 列表1.当列表1更改时，您可以在 选项被绘制后显示表单的其余部分在。事件驱动模型之后非常好，因为你可以在表单的特定部分中绘制特定事件。一个 一步一步的过程很容易让用户关注并使事件更容易使用，而不会很麻烦。 摘要： ASP到ASP.NET需要在很多方面进行范式转换。一旦你习惯了它的b $ b，你就会想知道为什么你没有看到它是多么容易。在那之前，你很可能会在墙上撞到你的脑袋。我做到了！ - Gregory A. Beamer MVP; MCP：+ I，SE，SD，DBA **************************** ******************** 在盒子外面思考！ ********* ******************************************* Dimitris Pantazopoulos" < Di ******************* @ discussion.microsoft> 在留言中写道：57 ****** **************************** @ microsof t ... 大家好。我完全不同意ASP.NET事件处理模型。这是我在经过数周努力研究比MSPetShop更加逼真的网络应用程序后得出的最终结论;）我坚信事件处理模型很麻烦，很复杂，而且只是，嗯，......不可预测！最后但并非最不重要的是，与旧的ASP处理逻辑形成鲜明对比的是。下面是一个示例： - 在用户控件中放置一个下拉列表，并用一些项填充它。在上，SelectedIndexChanged事件只是将所选值保存在Session 变量中。 - 在几个Web表单中添加用户控件。 - 根据Session变量的值，您想要在Web表单中显示不同的结果。这是一个经典错误判断和误解的例子，尤其是从ASP迁移到ASP.NET的人们的。考虑事实： - 每个Web表单的Load事件在用户控件的Load事件之前触发。 - 因此，你无法真正说出会话中的内容...... -...因为用户控件会在网页表单之后触发其代码。 - 网页表单必须...等待....对于用户控制...一切。 这只是其中一个案例。我相信Load事件通常是在处理模型中错误的地点和时间处理。 IsPostBack只是防止地狱爆发的最后一分钟借口。 当然，我知道有些人说这种帖子是纯粹的讽刺，其他人可能会发现它只是b $ b太大声，甚至疯狂。但请考虑每天以b $ b为单位在软件公司工作的程序员（而不仅仅是为了测试和娱乐!!!）而且只是为了让事情发挥作用而只需要。他们肯定不需要所有这些混乱。 dimitris
On Fri，2004年7月2日05:24:02 -0700，Dimitris Pantazopoulos < Di ******************* @ discussion.microsoft>写道： - 网络表单必须...等待....用户控制......一切。
Hi Dimitris： 我认为你可以采取两种不错的方法。 1）让用户控制泡沫直到页面的事件。现在，如果 页面对用户控件中发生的事情感兴趣，它可以 订阅该事件并确切知道它何时发生。 odetocode/Code/94.aspx 2）为用户控件提供一个公共属性供页面检查。 这样可以将Session集合从循环中删除，你就会正确使用 到您需要的信息来源。 这有帮助吗？ - Scott www.OdeToCode
Hi all. I completely disagree with the ASP.NET Event Handling model. This is a final conclusion I came to after weeks of hard work on a quite-more-realistic-web-app than the MSPetShop ;) I firmly believe that the Event Handling model is cumbersome, complicated, unefficient and just, well, ...unpredictable! Last but not least, it comes to a complete contrast with the old ASP processing logic. Here is an example: -Place a dropdownlist in a user control and fill it with some items. On the SelectedIndexChanged event just save the selected value in a Session variable. -Add the user control in a couple of web forms. -Assume that depending on the value of the Session variable you want to display different results in your web forms. This is a classic example of misjudgement and misunderstanding especially for people migrating from ASP to ASP.NET. Consider the facts: -The Load event of each web form fires BEFORE the Load event of the user control. -Thus you cannot really say what''s in your Session var... -...because the usercontrol will fire its code AFTER the web form does. -The web form has to ... WAIT.... for the usercontrol ... SOMEHOW. This is just one of the cases. I believe the Load event is generally handled in the wrong place and time in the processing model. The IsPostBack is just a last-minute-excuse to prevent hell broke loose. Of course, I know some of you say this kind of post is pure sarcasm, others may find it just too LOUD or even CRAZY. But please think about programmers working in software companies in a daily basis (and not at home just for testing and fun !!!) and are simply trying to make things work. They surely do NOT need all this mess. dimitris
解决方案 Thanks for your opinion, and I must say there are many other web technologies available if asp isn''t to your liking, nobody is forcing asp down your throat. Personally, I''ve never had a problem with the event model, have you ever given any thought that you are going about your design the wrong way? How long have you bee programming to know absolutely there is no other way to do this? If I was doing this, my usercontrol would expose it''s own event which my webform would handle, and make the appropriate changes to the form. I see no need to use a session variable in this situation. --Michael "Dimitris Pantazopoulos" <Di*******************@discussions.microsoft > wrote in message news:57**********************************@microsof t... Hi all. I completely disagree with the ASP.NET Event Handling model. This is a final conclusion I came to after weeks of hard work on a quite-more-realistic-web-app than the MSPetShop ;) I firmly believe that the Event Handling model is cumbersome, complicated, unefficient and just, well, ...unpredictable! Last but not least, it comes to a complete contrast with the old ASP processing logic. Here is an example: -Place a dropdownlist in a user control and fill it with some items. On the SelectedIndexChanged event just save the selected value in a Session variable. -Add the user control in a couple of web forms. -Assume that depending on the value of the Session variable you want to display different results in your web forms. This is a classic example of misjudgement and misunderstanding especially for people migrating from ASP to ASP.NET. Consider the facts: -The Load event of each web form fires BEFORE the Load event of the user control. -Thus you cannot really say what''s in your Session var... -...because the usercontrol will fire its code AFTER the web form does. -The web form has to ... WAIT.... for the usercontrol ... SOMEHOW. This is just one of the cases. I believe the Load event is generally handled in the wrong place and time in the processing model. The IsPostBack is just a last-minute-excuse to prevent hell broke loose. Of course, I know some of you say this kind of post is pure sarcasm, others may find it just too LOUD or even CRAZY. But please think about programmers working in software companies in a daily basis (and not at home just for testing and fun !!!) and are simply trying to make things work. They surely do NOT need all this mess. dimitrisI disagree with you, but my disagreement comes from completing the trip through the valley of frustration and coming to an understanding of the new model. I see frustration as a normal part of the process of change in methodology. Most ASP devs, myself included, try to make ASP like pages in ASP.NET. This mix of paradigms makes it extremely hard. Often times, it is easy to shift language syntax to get through the paradigm shift than it is to continue in a familiar language. You can then go back to your old language. I did this by moving from VBScript ASP to C#. I now do both C# and VB .NET. Let''s examine a few things: Page_Load - designed to set a page when it loads. For optimal efficiency and minimal hair pulling, this sets up a page on first load only. If your Page_Load is more than a few lines, you are most likely doing it wrong. Example of bad Page_Load: protected void Page_Load(object sender, EventArgs e) { if(!Page.IsPostBack) { //Do a lot of stuff, checking for numerous QueryString vars } else { //Do a lot of different stuff, as the form is being submitted } } Proper: protected void Page_Load(object sender, EventArgs e) { if(!Page.IsPostBack) { //Do only what is necessary for initial state of page } } protected void Button_Click(object sender, EventArgs e) { //Do what is necessary for this page when this button is //clicked. If you have some postback controlled in Page_Load //move it to another routine and call it from here instead //Do not run any postback code in Page_Load UNLESS it //is run on EVERY postback. If it is conditional, run it from here //Refactor your code to fit this model } Controls controlling controls: You have a couple of choices here, each can be painful: 1. Run it through client script 2. Run it on the server side For small lists, client side is a perfectly viable option to the postback model, as it avoids a trip to the server. This trip is not really heavy, but heavier than setting a short list. If the list is long, however, client side script is a bulky solution. For example, pick a country, country sets states list. Pick a state, state sets city or county list. To do this all client side, you download MBs of script, which makes the app unusable in anything other than extreme broadband. A server trip is in order. One Methodology: I prefer to build up a page from nothing. This comes from my paranoia over inaccurate data. Turn everything off as state 1 and turn things on based on specific conditions. If a user has to pick from one list first, only show list 1. When list 1 changes, you can show the rest of the form, after choices are painted in. This follows the event driven model rather nicely as you can hit specific events to paint in specific parts of the form. A step-by-step process is easy for the user to follow and makes events rather easy to use, without being cumbersome. Summary: ASP to ASP.NET requires a paradigm shift in many ways. Once you are used to it, you wonder why you did not see how easy it was. Until then, you are likely to beat your head against the wall. I did! -- Gregory A. Beamer MVP; MCP: +I, SE, SD, DBA ************************************************ Think Outside the Box! ************************************************ "Dimitris Pantazopoulos" <Di*******************@discussions.microsoft > wrote in message news:57**********************************@microsof t... Hi all. I completely disagree with the ASP.NET Event Handling model. This is a final conclusion I came to after weeks of hard work on a quite-more-realistic-web-app than the MSPetShop ;) I firmly believe that the Event Handling model is cumbersome, complicated, unefficient and just, well, ...unpredictable! Last but not least, it comes to a complete contrast with the old ASP processing logic. Here is an example: -Place a dropdownlist in a user control and fill it with some items. On the SelectedIndexChanged event just save the selected value in a Session variable. -Add the user control in a couple of web forms. -Assume that depending on the value of the Session variable you want to display different results in your web forms. This is a classic example of misjudgement and misunderstanding especially for people migrating from ASP to ASP.NET. Consider the facts: -The Load event of each web form fires BEFORE the Load event of the user control. -Thus you cannot really say what''s in your Session var... -...because the usercontrol will fire its code AFTER the web form does. -The web form has to ... WAIT.... for the usercontrol ... SOMEHOW. This is just one of the cases. I believe the Load event is generally handled in the wrong place and time in the processing model. The IsPostBack is just a last-minute-excuse to prevent hell broke loose. Of course, I know some of you say this kind of post is pure sarcasm, others may find it just too LOUD or even CRAZY. But please think about programmers working in software companies in a daily basis (and not at home just for testing and fun !!!) and are simply trying to make things work. They surely do NOT need all this mess. dimitrisOn Fri, 2 Jul 2004 05:24:02 -0700, "Dimitris Pantazopoulos" <Di*******************@discussions.microsoft > wrote: -The web form has to ... WAIT.... for the usercontrol ... SOMEHOW.Hi Dimitris: There are two decent approaches I think you could take. 1) Have the user control "bubble" the event up to the page. Now if the page is interested in what is happening in the user control it can subscribe to the event and know exactly when it happens. odetocode/Code/94.aspx 2) Give the user control a public property for the Page to examine. This cuts the Session collection out of the loop and you''ll go right to the source of the information you need. Does this help? -- Scott www.OdeToCode
更多推荐
我完全不同意
发布评论