De ce am început să evit ASP.NET WebForms (când pot)

De ce? Unul din motive – complexitatea. În încercarea de a emula programarea RAD, component-based din WinForms și pentru web applications, WebForms a ajuns rapid un elefant căruia îi descoperi complexitatea doar când te lovești de cazuri non-triviale.

Pentru cine nu e convins, o privire pe comentariile din codul sursă de la WebForms e suficientă.
(nu contează textul în sine, ce transmit acele comments, ci mărimea lor și complexitatea la care s-a ajuns – un smell ușor de detectat)
Toate acestea într-o singura clasă de bază, “aparent” simplă – ListControl:

internal bool SaveSelectedIndicesViewState {
get {
// Must be saved when 
// 1. There is a registered event handler for SelectedIndexChanged or TextChanged.
//    For our controls, we know for sure that there is no event handler registered for 
//    SelectedIndexChanged or TextChanged so we can short-circuit that check. 
// 2. Control is not enabled or visible, because the browser's post data will not include this control
// 3. The instance is a derived instance, which might be overriding the OnSelectedIndexChanged method 
//    This is a bit hacky, since we have to cover all the four derived classes we have...
// 4. AutoPostBack is true and Adapter doesn't support JavaScript
//    For ListControls to behave the same on mobile devices
//    that simulate AutoPostBack by rendering a command button, we need to save 
//    state.
// 5. The control is paginated. 
// 6. The control contains items that are disabled.  The browser's post data will not 
//    include this data for disabled items, so we need to save those selected indices.
   // always save the selectedindex
   // When we've databound, we'll have items from viewstate on the next postback. 
   // If we don't cache the selected index and reset it after we databind again, 
   // the selection goes away.  So we always have to save the selectedIndex for restore
   // after databind. 
   cachedSelectedIndex = value;
public virtual string SelectedValue { ...
  // if we're in a postback and our state is loaded or the page isn't a postback but all persistance is loaded
  // but the selection doesn't exist in the list of items, 
  // throw saying we couldn't find the selected value.
// When IDMode=Static but has no ID, what should the item IDs be? Reverting to AutoID behavior. 

Mergând un pic în clasa de bază, găsim asta:

// If the control was added after PagePreLoad, we still need to databind it because it missed its
// first change in PagePreLoad.  If this control was created by a call to a parent control's DataBind 
// in Page_Load (with is relatively common), this control will already have been databound even 
// though pagePreLoad never fired and the page isn't a postback.
if (!Page.IsPostBack) { 
    RequiresDataBinding = true;
// If the control was added to the page after page.PreLoad, we'll never get the event and we'll
// never databind the control.  So if we're catching up and Load happens but PreLoad never happened, 
// call DataBind.  This may make the control get databound twice if the user called DataBind on the control
// directly in Page.OnLoad, but better to bind twice than never to bind at all. 
else if (IsViewStateEnabled) { 
    RequiresDataBinding = true;
This entry was posted in .NET, Web and tagged , , . Bookmark the permalink.

3 Responses to De ce am început să evit ASP.NET WebForms (când pot)

  1. ignatandrei says:

    Inainte de ajax parca mai mergea…

  2. Andrei Rinea says:

    Adio din 2007. Viewstate a fost o mare durere…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s