posts - 23,  comments - 82,  trackbacks - 0

I know all of you are thinking that I'm stupid. Of course, everybody knows Web Forms are objects. But why, if everybody knows, not everybody thinks on it when developing web applications?!

You can have the best Architecture, the best Data Access Layer, the best Business Rules and Objects.... what happens with pages?! Pages are always the worst part of any web applications I've ever seen. Coupling, modularization, abstraction, maintainability... are things that doesn't be cared in web pages.

I know (and suffered each day) about client requirements. Windows designs tried to put directly into web pages that make us to code lots of lines in JavaScript. But really I think that this isn't the main problem. I think the problem is that when a page is finished, you can ask the developer who has coded about what happens if the user clicks here and the change this value and... he doesn't know.

I think a way of improve Web Applications development is taking care about the design of the front-end. Pages are the only way users can scratch our code, because the front-end is where they can interact with the application. Is good to design "the perfect" Architecture and so on, but thinking that pages are just objects with some properties and some data showed in a different way depending on those properties.... I think the time spent developing the front-end and the number of bugs on it shouldn't be so higher.

I'm writing an article about it but I'm not sure when it could be finished. Somethings included will be.

- Page_Load always execute, even when the page won't be rendered again (in navigation, when you close it). Is this line really necessary out of the typical if (!IsPostBack)... ? Think about it and try to refactor it. 

- Try to design your pages as decoupled as you can from the rest of the application. This is even more important if the coupling is between pages.

- Use private properties as flags to configure your object (your page). You can do things like this if you are waiting for that key from the previous page, or use ViewState if you just need this property during the postbacks.

 private long theKeyINeedToLoadData 
{ 
 get 
 { 
  if (Session["theMagicKey"] != null) 
  { 
   return (long)Session["theMagicKey"]; 
  }
  return -1; 
 } 
 
 set 
 { 
  Session["theMagicKey"] = vale; 
 } 
} 

- Check this "really needed to work" properties as early as possible, and if you detect a problem stop execution. Show an error, redirect to some general page... but I'm sure at this point you already know something will goes wrong if you continue to the end of the life cycle.

I hope I have enough time to finish this article, and then put it here to argue with all of you and learn together about it.

Feel free commenting anything about this, I think is really important and interesting.

posted on Thursday, February 02, 2006 9:48 PM

Post a new comment about this topic
Title  
Name  
Url

Comments   
Protected by Clearscreen.SharpHIPEnter the code you see: