<< .NET 2.0 nullable types: furrrba MS ! ! ! | Home | Eventi abstract e virtual e stranezze del compilatore C# !?! >>

Quando ASP.NET ostacola il buon disegno !

   Nel implementare una applicazione uso gli oggetti del framework .NET, ovviamente! Per quanto cerchi di applicare DIP (il principio di buon disegno OO chiamato "Dependency Inversion Principle") il framework finisce comunque per avere un ruolo nel facilitarmi o complicarmi l'implementazione delle scelte di disegno che ho fatto.

    Questi i due casi in cui ASP.NET mi ha reso complicata o impossibile una buona scelta di disegno OO:

  1. Cosa? Estrarre delle nuove classi da una classe (ossia fare Refactoring) quando il codice  diventa troppo corposo e complicato e parti di codice sono duplicate e fare evoluzioni (togliere bug, aggiungere o cambiare funzionalità) richiede di intervenire a macchia di leopardo su parti del codice apparentemente non correlate.
    Chi? I Web User Control .ASCX
    Perché? Perché il codice da estrarre fa uso di funzioni di System.Web.UI.UserControl che sono accessibili solo dalla classe derivata (come la property ViewState o il metodo LoadViewState) e non da una diversa classe.
  2. Cosa? Separare i dati (lo stato della appplicazione e i dati del dominio applicativo) dalla loro presentazione e dal controllo del flusso di interazione utente. Ossia applicare il pattern MVC.
    Chi? I WebForm ASP.NET.
    Perché? Ad esempio per estrarre responsabilità dalla singola pagina e inserirle in classi diverse è necessario usare funzioni poco conosciute (come usare HttpContext per accedere alla Session da classi che non derivano da Page1) o implementtare funzioni di sistema assenti (come la property CurrentDocument che nella classe System.Uri è privata ma invece è utile per implementare il controllo della navigazione1)
  3. ...

Lascio ai nostri MVP (che fa rima col pattern MVC) l'onere di informare Microsoft di queste difficoltà avvertite da un  programmatore .NET (ma sono il solo??? voi come avete risolto questi casi? fatemi sapere).

Se non posso conoscere i motivi per cui il Team di ASP.NET ha scelto in entrambi i casi (Web Form e Web User Control) di disegnare le cose in questo modo posso invece rilevare che in entrambi i casi le funzioni del framework sono rese disponibili attraverso l'ereditarietà invece che il contenimento (scelta di disegno notoriamente sconsigliabile) e questo potrebbe soffrire del problema della FragileBaseClass.

Bene... dopo questo sfogo posso tornare a lavorare al user control DataTableEditor, dopo aver combattuto duramente col problema al punto 1 mi aspetta un po' di refactoring (per eliminare le smell di 'codice duplicato',  'shotgun surgery' e 'lunghe liste di switch/if ').

---------
(1) Vedi l'esempio scaricabile della sessione Refactoring Applied dal Workshop UGI Architecture & Management

Print | posted @ mercoledì 11 maggio 2005 10.16

Comments on this entry:

Gravatar # re: Quando .NET ostacola il buon disegno !
by Damiano at 11/05/2005 10.24
HttpContext poco conosciuto?!?
Fose è meglio che ti metti a studiare un po' .net prima di criticarlo...
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Luca Minudel at 11/05/2005 12.19
credo di conoscere .net quanto basta per poter fare una critica costruttiva e discuterla con gli altri .

nella vita reale quando sviluppo software in un team ci sono sviluppatori con diversi livelli di preparazione (la maggior parte sono junior, intermedi ma purtroppo difficilmente senior visto che costano e sono rari).

adottare tecniche meno conosciute (dal "grande pubblico") mi richiede tempo (spiegazioni, primi errori, etc) che ha un peso sull'economia del progetto.

è a questo che mi riferisco nel post.
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Lorenzo Barbieri at 11/05/2005 12.27
Per Damiano... certo che c'è modo e modo di dire le cose, e in questo caso sei stato veramente scortese e senza neanche firmarti... :-(
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by http://blogs.ugidotnet.org/marki at 11/05/2005 12.33
mi unisco anke io al commento di Lorenzo, spiacendomi di essere OT nel post di (luka). Damiano forse dovresti leggere un po meglio quello che dice (luka) senza fermarti a quello che un linguaggio può e non può fare. (luka) ti parla di archietture e/o gestione di progetti... ok il commento termina qui. (skusa luka).
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Luca Minudel at 11/05/2005 14.07
Grazie a Lorenzo e M.rkino, concordo con voi.

Il punto è che il disegno con cui sono realizzati i Web Form ASP.NET ed i Web User Control .ASCX rendono difficile portare fuori responsabilità dalla pagina o dal controllo.

Ad esempio è un dato di fatto che nel mondo .NET non esiste una implementazione diffusa del pattern MVC e anche quelle disponibili vengono usate raramente.

Non credo che l'unica ragione si l'incapacita di noi programmatori .NET di riconoscere ad esempio i vantaggi del pattern MVC o di non saper fare refactoring o che l'unica ragione si l'incapacita dei frameworker che non hanno saputo proporre una implementazione valida del MVC o metodi di refactoring per ASP.NET.
Credo piuttosto che il disegno delle pagine e dei controlli fatta dal team ASP.NET renda queste cose più difficili... troppo per apprezzarne i vantaggi.

Nel mondo Java questi problemi _sembrano_ non esserci.

La cosa mi inquieta!
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by theEvil at 11/05/2005 14.38
Ciao,

non sono certo un esperto di design ma a mio parere MS ha creato un MVC tutto suo.
Ossia un MVC che per un certo senso è basato sul "code-behind".

M = DataSet , custom classes
V = aspx
C = aspx.cs (con c#)

Il risultato finale non è certo come Struts nel mondo Java, ma la produttività, a mio parere, anche quella non è paragonabile (punto decisamente a favore di MS).
Secondo me, MS punta e forse sempre punterà sulla produttività più che su un'architettura impeccabile.

Sbaglio ?
Certamente Java è molto più rigoroso da questo punto di vista, ma forse .Net ha saputo equilibrare con dosi migliori i 2 aspetti (metologie vs produttività).
Il risultato è che si possono scrivere ottime applicazione (che secondo me non hanno più nulla da invidiare a Java) in tempi accettabili.

Tutto ovviamente IMHO.

Ciao.
theEvil
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Luca Minudel at 11/05/2005 15.57
Ciao theEvil,

quanto dici mi fa pensare che molti casi (il 50% ?) la soluzione di ASP.NET eccelle in produttività (ricordo ora di aver letto che il modello di astrazione dall'html di ASP.NET è stato copiato dal mondo Java e questa è una conferma delle sue qualità).

Ma cosa accade quando la quantità di funzioni implementata in una singola pagina (logica di presentazione o di interazione utente per quella specifica pagina) o in un singolo User Control iniziano a crescere cosi tanto che diventa facile introdurre un bug, difficile eliminarlo e difficile aggiungere nuove funzionalità?
La produttività ecco che cala.
Ed esistono molti casi (l'altro 50% ? progetti Enterprise un po complicati) come questi in cui il codice in una singola pagina o user control è più di quanto ci stà bene.

IMHO quando l'architettura è buona supporta bene la produttività in entrambe le circostanze.

Ecco esempi concreti così mi spiego (e do elementi per controbattere ;-) .

1) lo user control che stò sviluppando è cresciuto cosi tanto che iniziava a diventare impossibile districarmi nel codice e proseguire lo sviluppo delle funzionalità.
Seguendo quanto suggerito da Design Pattern e Refactoring ho individuato diverse responsabilità (nel mio caso sono Stato, Layout, Logica, Interfaccia Pubblica) per spalmarle su classi diverse.
Per i problemi che dicevo, fare questo è stato più difficile di quanto poteva perchè il controllo ASCX mi ha costretto ad usare l'ereditarietà invece che il contenimento (ossia le classi di Stato, Layout, Logica e Interfaccia Pubblica sono in relazione di ereditarietà con lo user control invece di essere solo referenziate dallo user control).

2) Il pattern MVC di MS basato sul code-behind funziona per una singola pagina, ma quando l'interazione utente è spalmata su pagine diverse serve che

M += stato complessivo applicazione
V += Page2.aspx , Page3.aspx, ...
C += gestione navigazione tra le diverse pagine

Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Leoncini Marco at 11/05/2005 16.29
durante lo sviluppo mi sono trovato alcune volte nella situazione che descrivi, è un motivo per cui non utilizzo più UserControl ma solo WebControl, ma per inciso ViewState è sempre protected, l'ho aggirato in maniera poco elegante, qundo necessario con un bel new

ciao marco
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Luca Minudel at 11/05/2005 17.48
Ciao Marco, in che modo potrei usare anch'io i WebControl al posto di User Control per facilitare lo spostamento di responsabilità dallo user control a classi esterne senza usare l'ereditarietà?

Oltre al ViewState non hai avuto problemi con gli altri membri delle classi base di tipo protected? (antendo il bisogno di accederci dalle classi che hai creato estraendo responsabilità dal WebControl)

ciao (luKa)

Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Leoncini Marco at 11/05/2005 18.21
con altre propietà (o metodi) mi sono trovato in difficoltà, ultimamente lavoro molto con classi derivate da Style, eseguo l'override del metodo CreateContolStyle del WebControl per restituire un istanza dalla mia classe che si occupa di creare un foglio di stile da inserire poi nel tag head.

la classe style a molti menbri definito protected inernal , alcuni avrebbero fatto comdo propio come public


p.s. è mai possibile sbagliare 3 volte di fila il test? per non sembrare un bot :)
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Marco staffoli at 15/05/2005 18.11
Salve a tutti

Sto valutando alcuni linguaggi di programmazione proprio in base a criteri di
- produttività
- scalabilità
- robustezza
che essi consentono.

Luka, non sei il solo a pensare che "ASPnet ostacola i buon disegno"... sono molti quelli che dicono che le webform sono solo una questione di marketing di Ms e non una reale tecnologia su cui costruire applicazioni che rispettino i criteri di cui sopra.

Effettivamente rispettare un pattern MVC ha portato le mie applicazioni ad una maggiore robustezza.

Web form a parte (forse) anche con asp.net si riesce a creare applicazioni mvc

http://mavnet.sourceforge.net/

In java esistono moltissimo fremework di questo tipo già da anni. Java infatti incoraggia il pattern MVC.

E per aumentare il distacco tra presentazione e codice suggerirei di dare una occhiata qui

http://nvelocity.sourceforge.net/

Anche di questi progetti in java ce ne sono tanti. Vengono detti Template engine. Io ho provato Velocity e FreeMarker e, soprattutto quest'ultimo l'ho trovato geniale, praticamente perfetto.

Spero che facciano presto il porting in .net
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Marco staffoli at 15/05/2005 18.19
Qui c'è un articolo in italiano che da delle dritte su come implementare mvc in .net

http://www.devspy.com/Art/Lang/Art.aspx?lang=16&id=00144

ps. forse in .net non si parla molto di mvc e pochi lo conoscono perchè Ms propone a spron battuto l'astrazione delle webform e tutti si accontentano di quella filosofia.
Onestamente non so che farmene di pagine piene di controlli, preferiscon di gran lunga interfacce più semplici e snelle e di conseguenza più robuste.
Gravatar # re: Quando ASP.NET ostacola il buon disegno !
by Luca Minudel at 17/05/2005 12.57
Ciao Marco, guarderò i link che hai segnalato. Sono dubbioso per il fatto che ad esempio nel mondo Java Struts appare come skill richiesto anche nelle offerte di lavoro e in .NET ad esempio nunit è uno "standard defacto" mentre di mvc in .NET ce ne sono a decine e nessuno riesce ad emergere.

Se hai commenti / impressioni sui tool che hai segnalato, li leggo volentieri!
Gravatar # Esperienza di Refactoring con ReSharper: resoconto
by (luKa) at 19/05/2005 22.10

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 7 and 2 and type the answer here: