Come rigorosamente segui l'architettura n-tier e separazione degli interessi tra gli strati nei vostri progetti?

Question

suppongo la maggior parte degli sviluppatori hanno un'idea di architettura multi-layer. Abbiamo DAL (Data Access Layer), abbiamo BLL (livello di logica di business) e da qualche parte vicino alla fine della strada noi abbiamo la nostra interfaccia utente. Se si dispone di un progetto che segue in qualche modo questi principi, si fa a mantenere (o almeno provarci) per mantenere / mettere le cose al loro posto concettualmente? Sono particolarmente interessato a grandi applicazioni aziendali in cui si lavora insieme a molte altre persone. Chiaramente si può fare quello che vuoi con il vostro progetto giocattolo privato, inventare qualsiasi tipo di un'architettura e bastone ad esso. Non è così facile con i grandi progetti in cui un sacco di persone hanno contribuito al software o disordine generale.

Per esempio, mi è capitato di vedere le cose come componenti dell'interfaccia utente che vanno direttamente al database per prendere un po ' "mancanti" di dati in più che BL non fornisce, anche sia UI e BL lavorare con elementi di basso livello come campi della tabella in cui a mio parere dovrebbero delegare queste operazioni al livello inferiore cioè DAL. E 'stato particolarmente triste quando dopo aver discusso le cose con il ragazzo sviluppatore senior ho visto che non ha visto un problema con questo a tutti.

Naturalmente me assumere e chi condivide il mio punto di vista sono solo di essere perfezionisti, ma ho visto chiaramente una conseguenza molto disadvantegous nel senso che mi ha portato periodi di tempo prolungati in alcuni dei miei compiti di tracciare tutti i "parallelo" percorsi che i dati è in viaggio per e dal database e per identificare chi e in che modo può ora essere influenzato dalla nuova funzionalità ho implementato. Il mio modo di vedere, questi sono aumentati ulteriormente i costi di sviluppo / manutenzione sovraponderazione qualche risparmio, quando qualcuno ha deciso di incidere rapidamente la roba e chiudere l'operazione nel più breve tempo possibile.

Sei progetti "puro" o hanno abbandonato l'idea di tenere la linea chiara tra gli strati molto tempo fa? Se ancora tenendo la destra, come si fa a trattare con i colleghi che non capiscono queste cose o non si preoccupano di loro solo la costruzione di soluzioni "su misura" e hack di hacking tutto il tempo? O a un certo punto nel tempo è stato interrotto in lotta con il mulino a vento e accettato come vostra punizione ?. EDIT: Un po 'sorpreso del fatto che non molte persone si sono interessati al problema. E 'questo il segno più non si preoccupano?

Answer 1

Il più complicata la nostra applicazione ottiene, la separazione più importante delle preoccupazioni diventa.

A 100 klocs, l'applicazione è stata una grande blob, come codice di business molto in classi di form, come in qualsiasi altro luogo e mette in metodi di modulo dalle classi di business. Con molto pianto e stridore di denti, abbiamo separato la logica di business dalla logica di visualizzazione. Ogni classe che serve per avvisare l'utente del suo progresso sollevò un evento che è stato affondato da l'interfaccia utente. E, per un po ', tutto andava bene con il mondo.

Circa 200 klocs, abbiamo aggiunto uno strato di dati. L'architettura della nostra applicazione è stata tale che la maggior parte dei nostri dati sono stati elaborati non appena entrato e subito scartato. La maggior parte delle informazioni di configurazione è stato memorizzato nel applicazione di terze parti con cui il nostro condiviso un rapporto simbiotico. Ma, impostazioni stavano cominciando ad accumularsi in tutti i tipi di angoli strani. Noi ci siamo ritrovati con tre sistemi di gestione della configurazione, il tutto intessuto nella logica di business. Con un'ampia riscrittura, siamo stati in grado di separare le informazioni di configurazione nel proprio livello e il trattamento di streaming di dati in un altro livello.

vicino alla linea KLOC 250, abbiamo deciso di concludere il nostro rapporto con il fornitore di terze parti e rendere stand-alone la nostra applicazione. Abbiamo iniziato una riscrittura massiccio e, per la prima volta, aggiunto un database effettivo alla nostra applicazione. Perché abbiamo avuto chiare linee tra le informazioni di streaming, l'archiviazione dei dati, e la logica di business, questa è stata un'integrazione abbastanza senza soluzione di continuità.

Ora, si avvicina a 500 klocs, ci stiamo muovendo l'applicazione per un'architettura grid-based. Non solo l'interfaccia utente separata dalla logica aziendale su un altro computer, il calcolo effettivo dei preventivi e ordini che l'applicazione invia sarà carico bilanciato e sparsi per massimizzare l'efficienza. Questo sarebbe impossibile senza un'architettura a più livelli.

In ogni fase di crescita, eravamo o aiutati da una netta separazione oppure ostacolata dalla nostra groviglio di comunicazione, i dati, le imprese, e interfaccia utente. Probabilmente non è stata una preoccupazione più importante di quella separazione, nella creazione di questa applicazione.

Answer 2

Questa è una grande domanda! Qualcosa di ogni sviluppatore ASP.Net bisogno di pensare. Probabilmente otterrete un sacco di risposte, mi piacerebbe incoraggiare queste idee di base di buon senso.

- Prendere in considerazione la semplicità e la velocità di consegna come parte di un'architettura "di successo", non solo "purezza". Cercate di equilibrio tra tenuta di ideali architettonici, e di essere pratico.

- In generale, sembra avere un senso di dividere il codice di fuori in strati come si parla. Vorrei suggerire, tuttavia, che per la logica specifica pagina, potrebbe essere lasciato nella pagina se è più semplice / più veloce - perché creare oggetti di business generici per il codice che è solo usato in un unico luogo. Come è stato detto "ottimizzazione prematura è la radice di tutti i mali.”.

-. Tenere gli strati e la complessità al minimo per ridurre i tempi di codifica e di migliorare la leggibilità e la manutenibilità

Ci sono molti puristi in questo sito che amano fare l'architettura per il sito di architettura - utilizzare l'architettura come strumento per fornire una soluzione ad un problema di business, non come solo una forma d'arte per la sua fine a se stesso, lascia che sia un utile strumento piuttosto che usando te.

Answer 3

Mantenere le preoccupazioni separata. E 'molto molto importante. Non mescolare UI con Biz e Biz con strato di dati. Lavorare con l'astrazione. Lavorare con l'astrazione fa anche il test (test di unità) più facile (li Mock). I rigorosamente continuo ogni strato in cui essa appartiene. Ricordate che il più alto costo in qualsiasi progetto è la sua manutenzione. Se si mescolano le preoccupazioni allora manutenzione sta andando diventare un incubo.

Answer 4

Abbiamo un app WinForms, e un'applicazione ASP.NET. Entrambi utilizzano lo stesso progetto di Business Objects (circa 140 classi).

Il progetto WinForms si compone di circa 350 classi di form e di controllo utente, e molto pochi (<10) di questi ha bisogno di metadati su se stessi dal database.

Il progetto ASP.NET ha circa 100 pagine aspx.

Abbiamo un livello di accesso ai dati che consiste di 5 classi, che si occupano di ADO.NET, fili e le transazioni. Essi convertono le richieste provenienti dai Business Objects in chiamate di SQL Server.

Gli strati di interfaccia utente (ad eccezione delle poche classi che hanno bisogno di metadati relativi a forma di dimensionamento) non fanno accesso al database a tutti. Anche le poche eccezioni passare attraverso il DAL come qualsiasi altra cosa.

lo strato di business non sa nulla il funzionamento interno dello strato di accesso ai dati, e quando è necessario i dati, sempre e solo le chiamate metodi pubblici sulle classi DAL.

Io non sono affatto un integralista quando si tratta di questo genere di cose, ma non abbiamo mai avuto bisogno di tagliare gli angoli su questo.

Così, in breve, puro al 100%. E 'semplicemente sempre funzionato meglio per farlo bene.

Ci piacerebbe avere un inferno di un buon motivo per allontanarsi da questo momento.

Answer 5

Code Monkeys e puristi sono un po 'come qualsiasi altro estremista nella vita.

Abbiamo di estrema destra e l'ala di estrema sinistra. Pochissime persone sono esattamente uno o l'altro e trovano una buona via di mezzo dove si siedono. Se non fosse stato per gli estremisti non sapremmo dove i confini si trovano.

Per quanto riguarda il codice di mio modo va. Ascolto il modo in cui i puristi di farlo. Vedo il codice scimmie andare circa i loro metodi. Io uso la mia esperienza di scegliere una via di mezzo che mi dà la giusta quantità di flessibilità e gestibilità con il tempo ho bisogno di produrlo e la quantità di denaro in realtà sto andando ottenere per farlo.

Answer 6

Più grande è il codice, più lungo è il ciclo di vita, i più differenti persone lavorano sul codice (entrambi contemporaneamente o durante il ciclo di vita), la più importante di separazione lei a strati è. In principio, sembra essere un po 'più di lavoro inutile, ma a lungo andare si paga per sé più volte.

Per quanto di far rispettare la separazione: Ecco perché il vostro capo programmatore o architetto tecnico ha bisogno di buone competenze trasversali e competenze tecniche puri. Si può cercare di far rispettare la separazione tecnicamente (vedi sotto), ma alla fine, è necessario convincere (o costringere) agli sviluppatori di mantenere il quadro pulita.

Ma questo non vuol dire che i mezzi tecnici per far rispettare la separazione hanno alcuna utilità. In realtà, ho scoperto che assicurare che "transfrontaliera chiama" sono un po 'difficile fare renderà persone trascorrono più tempo a pensare a cosa hanno veramente bisogno in-border-interfaccia croce, portando ad interfacce più pulite. Non importa se la difficoltà è tecnica (perché bisogna usare COM o CORBA) o qualcos'altro (è necessario compilare un modulo 7 pagina in triplice copia).