Qual è il modo giusto per sviluppare applicazioni ASP.NET al fine di separare l'accesso ai dati dalla visualizzazione dei dati?

Naviga le tue risposte
3

Sono attualmente coinvolto in una migrazione a TFS da SVN di un grande progetto che sarà suddiviso in cinque siti diversi. Questo progetto consente ad alcuni provider di inserire cinque diversi dati di prodotto nel DB aziendale. Come molte aziende là fuori, abbiamo un debito tecnologico che dovrebbe essere risolto (o almeno ridotto) con questa nuova organizzazione di progetto. Tuttavia, sono abbastanza nuovo per ASP.NET e anche il nostro software è ancora in esecuzione 2.0 .NET, quindi forse mi manca qualcosa o le cose dovrebbero essere fatte in un modo diverso al giorno d'oggi con 3.5 +.

Una di queste cinque parti sarà una nuova. Questo è quello che svilupperò. Per ottenere un alto grado di modularità, il codice del progetto corrente è suddiviso in diversi DAO ( Oggetto accesso ai dati ) in App_Code, *.ascx moduli che vivono in diverse parti della struttura del progetto, classi VB che ereditano da System.Web.UI.* (per ogni controllo visualizzato sul web) in App_Code e da molte stored procedure per fornire dati ai controlli. Inoltre, abbiamo diversi *.aspx che utilizzano <asp:PlaceHolder /> per visualizzare ciascuno dei controlli che ereditano da System.Web.UI.

La domanda arriva quando, per creare un semplice elenco a discesa <select> per visualizzare un elenco di provider, vedo che devo fare i seguenti passaggi:

  1. Crea una classe cProvider all'interno di App_Code, che eredita in definitiva da System.Web.UI, con un metodo che chiama il seguente oggetto DAOProvider.
  2. Crate un oggetto DAO specifico per connettersi al DB che ho bisogno.
  3. Crea un altro oggetto DAO, chiamato DAOProvider, che eredita dal precedente, con la chiamata a una stored procedure che recupera l'elenco dei provider.
  4. Crea quella stored procedure nel database.
  5. Crea un controllo .ascx per visualizzare <select> con le opzioni ottenute da cProvider .

Se sei ancora lì, ecco la mia domanda: è questo il modo giusto di fare le cose? Questo livello di modularità alto è il modo corretto di sviluppare applicazioni .NET mantainable? Devo seguire questo stile e organizzazione o dovrei prenderne un altro (per favore mi dia i suoi consigli)?

Dal mio punto di vista, dover fare tutti quei passaggi per dipingere un semplice elenco a discesa non segue affatto i principi KISS e diventa irraggiungibile se qualcun altro deve prendere questo progetto, sapendo che il codice è l'unica documentazione abbiamo.

EDIT: i collegamenti alla documentazione su questo argomento sarebbero molto apprezzati.

    
posta amb 21.12.2011 - 17:58
fonte

2 risposte

5

Non voglio proprio ripetere David, ma MVC è la strada da percorrere quando è importante una chiara separazione delle responsabilità. Divide la tua architettura in tre aree: i modelli (le tue classi), le viste (pensa a queste come le tue pagine web) e il controller (la logica).

Mi rendo conto che il passaggio potrebbe non essere possibile. Nei webforms, da dove viene la tua domanda, è possibile essere modulari senza esagerare. Non posso indicare esempi specifici, ma sì, sembra che il tuo attuale progetto sia eccessivamente architettato. Ancor prima di ASP.NET MVC, esistevano modi "MVC-ish" per creare webform ASP.NET con una buona separazione di responsabilità.

La mia migliore raccomandazione è non ripeterti . Se stai passando attraverso cinque passaggi per creare un'istantanea di un menu a discesa, dai un'occhiata a come puoi avvolgere alcuni (se non tutti) di questi passaggi in un processo più semplice. I generici sono una manna dal cielo per questo.

Infine, tornando alla raccomandazione MVC, ricorda che puoi e dovresti combinare webform ASP.NET e MVC quando opportuno .

    
risposta data 21.12.2011 - 19:27
fonte
2

Il sistema modulare parte ben al di sotto della linea di galleggiamento. Se stai discutendo su MVC vs WebForms hai già perso la guerra.

Quello che vuoi fare è separare le parti principali, non UI, del progetto in un assembly separato senza riferimento a System.Web.UI oa qualcosa del genere. I livelli dell'interfaccia utente fanno riferimento a questo assembly e chiamano i suoi metodi che generalmente devono restituire POCO e raccolte di POCO. L'interfaccia utente che si trova in cima a questo livello può quindi essere un throwaway relativamente semplice. Ricorda, l'interfaccia utente cambia ogni 3-5 anni mentre la memoria e la logica dei dati fondamentali possono durare decenni.

Per ottenere il tuo elenco a discesa dovresti:

a) Definisci una classe per i tuoi dati dell'elenco a discesa - abbiamo effettivamente un costrutto piuttosto generico che ha le cose giuste che servono, YMMV.
b) Definire una classe di servizio dati responsabile dell'accesso ai dati specifici con metodi appropriati.
c) Nella tua pagina / controller MVC, accedi al servizio e al metodo di servizio e metti i dati in un oggetto appropriatamente accessibile.
d) Nel modello, accedi all'oggetto e rendi <select>

Se si tratta di un elenco che utilizzi spesso, potresti prendere in considerazione l'idea di rendere un controllo utente / una vista parziale / un'azione secondaria come richiesto. La mia esperienza è che la modularità inizia davvero a cadere nel livello dell'interfaccia utente, dove una volta finisce per creare cose orribilmente complesse per gestire la personalizzazione che sarebbe stata semplicemente lasciata a mano su una buona logica di base.

    
risposta data 21.12.2011 - 20:32
fonte

Leggi altre domande sui tag

Voglio programma! [chiuso] Ubuntu, OpenSuse, il mondo di linux per uno sviluppatore web