Blog Stats
  • Posts - 171
  • Articles - 1
  • Comments - 207
  • Trackbacks - 5

 

Architecturing asp.net

Vorrei elencare un paio di cose che ho implementato nel progetto asp.net corrente e magari poter confrontare questa architettura con altre...per la serie non si finisce mai di imparare :)

1) generazione custom entities con CodeSmith
      - genero le classi per ogni tabella, a parte le tabelle di relazione m-n

2) generazione stored procedure e viste logiche con CodeSmith
      - genero le stored procedure di insert/update/delete per ogni custom entities
      - genero la vista select base (con associate join alle tabelle in relazione) per ogni custom entities

3) utilizzo degli Attributes di .net per mappature delle custom entities
      - ogni proprietà pubblica delle custom entities corrisponde ad un campo della tabella corrispondente
      - per ogni custom entitiy mappo stored procedure e vista di select base

4) Data Access Layer
      - abstract factory pattern per consentire provider dati diversi
      - utilizzo Reflection per gestire in automatico i metodi insert/update/delete
      - utilizzo Reflection per caricare in automatico l'entità singola e l'entità collection
      - non utilizzo Enterprise Library per accesso a sql server, ma una classe helper leggermente modificata rispetto 
        a quella del data access application block 2.0
      - gestisce in automatico ordinamento e paginazione
      - attraverso un attributo specifico per ogni metodo la query che deve essere eseguita.

5) Domain Layer
      - classi specializzate per ciascuna entità o gruppi di entità dello stesso dominio che si interfacciano direttamente
         con il DAL.
      - comunicazione con il DAL e con l'UI sempre tramite le custom entities.
      - i metodi eseguono le validazioni "di business"

6) UI
      - sistema tipo master page per le pagine aspx.
      - sistema a template(web part) per gli ascx
      - implementazione GridView e gestione theme sulla gridview(il tema è un file xml che viene tradotto in codice 
        compilato a runtime ed utilizzato sovrascriverne gli attributi.Preso spunto da articolo di Dino Esposito su msdn)
      - sicurezza gestita forms authentication e tramite asp.net roles e da codice
      - crypting querystring
      

I benefici di questa architettura dovrebbero essere almeno questi:

- ho già pronte stored e viste perfette per una buona percentuale dei casi
- non devo quasi mai scrivere codice diretto per la lettura o scrittura dei dati su sql server
- non devo preoccuparmi di gestire paginazione e ordinamento, è sufficiente passare i parametri di paginazione e ordinamento ai metodi del Domain Layer che a sua volta li gira al DAL che in automatico li gestisce.
- se cambia la struttura, rigenero le custom entities, le viste e le stored procedure base

Per quanto riguarda le performance, l'unico collo di bottiglia è reflection quando deve valorizzare le custom entities dalle query sql.

Vedremo con il proseguio del progetto se avremo i benefici prospettati, di più o di meno di quanto previsto.

Speriamo di più :)

 

 

 


Feedback

# re: Architecturing asp.net

Gravatar Moooolto interessante, avrai da divertirti di sicuro!

> gestione theme sulla gridview(il tema è un file xml .... Preso spunto da articolo di Dino Esposito su msdn)

puoi darmi qulche info in + a riguardo, e magari anche il link ?

15/05/2005 13.15 | Luca Minudel

# re: Architecturing asp.net

Gravatar l'articolo di Dino lo trovi qui:

http://msdn.microsoft.com/msdnmag/issues/04/05/CuttingEdge/default.aspx

saluti 15/05/2005 13.25 | Roberto messora

# re: Architecturing asp.net

Gravatar " non devo quasi mai scrivere codice diretto per la lettura o scrittura dei dati su sql server"...questo normalmente non mia piace proprio come soluzione. Perchè per molti sviluppatori è cosi brutto scrivere codice T-SQL?
E poi se ti sei gia fatto un Abstract Factory a che pro non scrivere codice? L'abstract Factory ti permette *proprio* di ottimizzare il codice SQL per ogni DB che vuoi usare. 15/05/2005 16.10 | Davide Mauri

# re: Architecturing asp.net

Gravatar L'articolo di Dino Esposito è quello che ha segnalato correttamente Roberto.
A differenza di quello di Dino, il mio theme genera il codice e lo compila in memoria, l'oggetto ottenuto viene poi messo in cache, creando una dipendenza della cache dal file xml del tema stesso.
Inoltre con il tema posso valorizzare non solo le proprietà del controllo ma anche gli elementi contenuti nelle sue collection.
Per esempio il mio GridView ha una collection Commands che contiene una serie di GridCommand, controlli che renderizzano ciascuno un particolare tipo di comando.
Con il tema posso definire anche quest'ultimi.

Per rispondere a Davide, il mio DAL non crea il codice T-SQL, ma è soltanto un wrapper ed un insieme di helpers per gestire le chiamate a query, viste o stored procedure che siano.
Per esempio nel DAL definisco:

[ExecuteCommand("select * from ...")]
public UtentiCollection ReadUtenti()
{
DataHelper.ExecuteRead(....);
}

piuttosto che

[ExecuteCommand(UseDefaultRead=true)]
public UtentiCollection ReadUtenti()
{
DataHelper.ExecuteRead(....);
}

per eseguire la vista di default mappata sull'entità UtentiCollection.

Se voglio, in tutti i metodi del DAL di cui sopra posso comunque scrivere del codice esterso che utilizzi le SqlClient per gestire i casi dove ho bisogno di performance et simili.

15/05/2005 20.51 | Luca Mauri

# re: Architecturing asp.net

Gravatar Ahhhh dicevo io ;-) Beh che dire? Ottimo lavoro! 16/05/2005 7.33 | Davide Mauri

# re: Architecturing asp.net

Gravatar Interessante.
Mi piacerebbe sapere come gestisci le foreign key nelle custom entities.
Ad esempio la classe Ordine avrà un reference alla classe Cliente. Quando carichi gli ordini come gestisci la reference?
Grazie.
15/07/2005 12.57 | Emanuele DelBono

# re: Architecturing asp.net

Gravatar Per ogni entità(mappa la tabella sul db) verifico le relazioni 1-1.
Per queste creo la proprietà relativa all'entità che mappa la tabella in relazione.
Nel caso di classe Ordine, avrò una proprietà Cliente di tipo classe Clienti.
Il caricamento dei dati dell'entita e delle proprietà che ne mappano le relazioni 1-1 è gestito tramite l'uso di query con alias particolari.

Sempre sull'esempio degli ordini, CodeSmith mi genera in automatico la vista logica di lettura degli ordini.
Questa vista mi estrae tutti i campi di ordini e tutti i campi delle tabelle in relazione 1-1.
I campi delle tabelle in relazione 1-1 li rinomina con degli alias composti da "nome tabella"_"nome campo".
In questo modo evito le colliosioni dovute a nomi di campi uguali su tabelle diverse.

Un altro metodo,usato da un mio collega nel suo framework, potrebbe essere quello di avere i nomi dei campi delle tabelle sempre univoci(ossia il nome del campo è già inizialmente equivalente a quello che per me è l'alias)

Il motore di accesso ai dati, quando esegue la query di lettura per l'entità Ordine(la ricava da un attributo messo su un metodo del data access layer) verifica la mappatura tra i campi della query e le proprietà della classe Ordine e di tutte le sue sottoclassi.
Per le sottoclassi verifica sempre l'alias ed il gioco è fatto.

Esempio:

classe Ordine: BaseEntity

[Mapping(Field="id", Alias="ordine_id")]
int ID;
[Mapping(Field="anno", Alias="ordine_anno")]
int Anno;
...
[Mapping(Field="id_cliente",
Alias="ordine_id_cliente")]
Clienti Cliente;

classe Cliente: BaseOrdini

[Mapping(Field="id", Alias="cliente_id")]
int ID;
[Mapping(Field="ragione_sociale",
Alias="cliente_ragione_sociale")]
string RagioneSociale;


vista logica:

select ordine.id, ordine.anno, ordine.id_cliente, ...
cliente.ragione_sociale as cliente_ragione_sociale,
...
from ordine
inner join cliente on .....


Spero di essere stato chiaro... ;)






15/07/2005 23.45 | Luca Mauri

Comments have been closed on this topic.
 

 

Copyright © Luca Mauri