Idea di progettazione software per architettura multilivello

Question

Idea di progettazione software per architettura multilivello

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

4

Attualmente sto studiando la progettazione di architetture multilivello per un'applicazione web based in MVC3. Ho già un'architettura, ma non sono sicuro che sia la migliore che posso fare in termini di estensibilità e prestazioni.

L'architettura corrente ha i seguenti componenti

DataTier (contiene oggetti EF POCO)
DomainModel (contiene oggetti relativi al dominio)
Globale (Tra le altre cose comuni contiene oggetti Repository per CRUD to DB)
Livello aziendale (logica aziendale e interazione tra dati e client e CRUD che utilizzano il repository)
Web (Client) (che parla con DomainModel e Business ma ha anche i propri ViewModels per creare e modificare le viste per es.)

Nota: sto usando ValueInjector per convertire un tipo di entità in un'altra. (che sta dimostrando un sovraccarico in questo desing. Non mi piace davvero farlo.)

La mia domanda è che ho troppi livelli nella suddetta architettura? Ho davvero bisogno di un modello di dominio? (Penso di sì quando espongo la mia Business Logic tramite WCF a client esterni).

Quello che sta succedendo è che per un semplice database lo si inserisce

(1) crea ViewModel

(2) Converti ViewModel in DomainModel for Business per capire

(3) Business Convertirlo in DataModel per repository e quindi i dati tornano nello stesso ordine.

Poche cose da considerare,

Non sto cercando una soluzione architettonica perfetta in quanto non esce. Sto cercando qualcosa che sia scalabile. Dovrebbe essere recuperabile (ad esempio utilizzando schemi di progettazione, interfacce, ereditarietà, ecc.) Ogni livello dovrebbe essere facilmente testabile.

Qualsiasi suggerimento o commento è molto apprezzato.

Grazie,

architecture

posta daehaai 19.08.2011 - 13:08

fonte

4 risposte

Leggi altre domande sui tag architecture

Controller che chiama più servizi Qual è il punto di calcolo di queste variabili in questo modo?

score 3 · Answer 1

Sarò molto generico, quindi mi dispiace se non è una novità per te, so che è noioso:

l'aggiunta di un livello aggiunge flessibilità ma costa alcune prestazioni
l'aggiunta di un livello non migliora la scalabilità (deve essere indirizzato separatamente su ogni livello che crea un collo di bottiglia)

Non conosco il tuo stack, ma le applicazioni simili di solito sono costituite da database , middleware (oggetto dominio con la relativa mappatura al database, logica aziendale) e frontend (interfaccia web per gli umani).

A seconda della situazione alcuni livelli possono essere uniti (database incorporato, logica aziendale e frontend come singola app web) - che è OK a condizione di mantenere pulite le dipendenze (nessun ciclo) e sai già dove tagliare per dividere i gemelli siamesi quando è necessario.

score 1 · Answer 2

Lo sviluppo a strati aumenta la complessità e lo sforzo di programmazione. È necessario giustificare ciò che un livello aziendale fornirebbe a un livello aziendale. Personalmente non conosco molti casi per la normale applicazione LOB per richiedere un livello aziendale per la scalabilità. Non sono sicuro di cosa sia esattamente Global, ma il resto sono la tua GUI e i dati che non puoi evitare di separare in alcun modo.

score 0 · Answer 3

Penso che gli archivi e il modello di dominio potrebbero essere compressi in un unico livello. I repository dovrebbero nascondere la logica CRUD di basso livello dai client (http://martinfowler.com/eaaCatalog/repository.html). Le query a loro devono restituire oggetti di dominio. Direi anche che gli archivi e il modello di dominio formano il contratto del livello di accesso ai dati. Il modello di business dovrebbe conoscere solo questo contratto. Se lo consideri come un tuo livello dipende da te e dai tuoi requisiti.

Dipende anche dalle tue esigenze, se vale la pena avere il tuo livello di logica aziendale. Se hai clienti diversi, sicuramente si. Consenti a tutti i tuoi clienti di accedere al livello aziendale, che a sua volta accede al livello di accesso ai dati attraverso una facciata, che conosce e interroga i repository e restituisce gli oggetti del dominio.

Se hai un solo cliente, ad es. la tua logica aziendale implica calcoli intensivi delle risorse o hai alcuni problemi di sicurezza, potrebbe essere comunque appropriato avere un livello aziendale dedicato, che lo incapsula. Altrimenti potresti includere la business logic in un'area (ben specificata) sul lato client. Dipende ...

score 0 · Answer 4

L'approccio predefinito dovrebbe essere tre "livelli" o moduli (accesso ai dati, azienda, interfaccia utente). Se ne hai di meno o di più, è meglio avere una buona ragione IMO come tre strati è la soluzione migliore per il 90% + di progetti aziendali. Più livelli significa correzioni e le modifiche richiedono più tempo. Meno strati possono causare confusione e resistenza al cambiamento.

Perché ho usato i "livelli" tra virgolette è che imporre che il livello aziendale si trovi tra l'accesso ai dati e l'interfaccia utente accoppia strettamente la logica aziendale al database. Ad esempio, cosa succede se l'utente vuole confondere situazioni ipotetiche con il tuo widget invece di ottenere informazioni sul widget che possiede? Questa è un'operazione che non richiede l'accesso ai dati. Il modo più semplice per farlo è New Widget - > Compila widget dall'interfaccia utente - > Chiama Widget.GetInfo () - > visualizza informazioni

Che cosa succede se un lavoro desidera accedere ai record ma non ha bisogno della logica aziendale? Gli affari e l'accesso ai dati dovrebbero essere separati, ma non direi che l'azienda si trova in cima all'accesso ai dati.