Un'alternativa all'architettura a 3 strati?

Question

Un'alternativa all'architettura a 3 strati?

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

3

Al lavoro, un architettura a 3 strati è il punto di riferimento ogni volta che un'applicazione web è necessaria.

Non mi dispiace, ma molte delle applicazioni che iniziamo, non sembrano avere una necessità iniziale per questo. Queste applicazioni sono praticamente solo un'interfaccia utente per il database. Ciò si traduce in un sacco di logica aziendale che invia i dati dal livello dati al livello di presentazione.

Ho trovato un'alternativa, tuttavia non l'ho ancora provato.

Architettura normale a 3 strati: (le frecce indicano la dipendenza)

Designaggiornato:

Invecepossofarlo,permettendomidimantenereunostratodiriferimentoindiretto,maavendoessosololeinterfacce,ilcostodiimplementazione(elapossibilitàdierrore)èridotto.

Designaggiornato,quandoleattivitàdiventanorilevantiinunafasesuccessiva:

Questo sarebbe simile a questo:

public class BusinessClass : IDataAccessInterface<string>
{
    public BusinessClass(IDataAccessInterface<string> dataRepository)
    {
        this.dataRepository = dataRepository;
    }

    public string Read()
    {
        var something = dataRepository.Read();
        //Do something with something
        return something;
    }
}

E il mio DI si sarebbe semplicemente iniettato un'implementazione da DataAccess implementation nel mio business class e il mio business class nella mia presentazione, che stava già utilizzando la stessa interfaccia.

La mia domanda è:

Ci sono degli inconvenienti a cui sono cieco?
Usi questo approccio (è ben distribuito)?
Qualche altro argomento che potrei portare con me al lavoro?

design c# layers

posta Chris Wohlert 03.07.2017 - 10:48

fonte

3 risposte

Leggi altre domande sui tag design c# layers

Come costruire un vocabolario condiviso dei termini del progetto su un team di sviluppatori? Programmazione asincrona composta in Java senza troppo GC

score 4 · Answer 1

Sembra che il tuo progetto sia influenzato dalla tua esperienza in Applicazioni che non hanno funzionalità diverse dalla lettura / aggiornamento di un database.

Normalmente non ci si aspetterebbe che il metodo esposto del livello della logica di business rispecchi il livello di accesso ai dati.

Per prendere l'esempio di Read() , mi aspetto che la logica di Business esca, Read(string userId) e che abbia qualche controllo logico che filtra i risultati di lettura DAL per restituire solo quelli che si applicano all'utente.

Una chiamata Update () sul DAL non verrebbe mai chiamata direttamente dall'interfaccia utente, ma ci aspetteremmo qualcosa come Purchase () o Calculate () che dopo l'applicazione delle regole di business potrebbe causare un numero di chiamate Update () al livello DAL.

Ovviamente se il cliente ha accesso completo all'aggiornamento delle chiamate, in ogni caso, potrebbe ignorare le regole aziendali come dover pagare per i tuoi acquisti !!

Riesco a vedere come può essere utile avere il mirror del livello aziendale che il DAL può aiutare, per quelle applicazioni in cui si sta semplicemente prototipando e si desidera semplicemente esporre un'interfaccia CRUD in modo che l'interfaccia utente possa lavorare con dati di esempio e l'utente possa fare clic su un processo e vedere lo stato persistente.

Ma consiglierei di attenermi al modello a 3 livelli e non ereditare l'interfaccia DAL nei tuoi oggetti di business. Non è molto più codice.

public class ShoppingBasket //Business Layer Object
{
    public Business(IDAL dataLayer)
    {
        this.dataLayer = dataLayer; // DAL object
    }
    public Order GetOrderForUser(string userId)
    {
        return this.dataLayer.Read();
        //todo:: implement business logic here later!
    }

    public void Purchase(Order order)
    {
         this.dataLayer.Update(order);
         //todo:: update the audit and billing tables!
    }

    //no requirement to implement this method. calling it directly would bypass the user filtering.
    //public Order Read()

    //no requirement to implement this method. calling it directly would bypass audit/payment requirements
    //public void Update(Order order)
}

score 0 · Answer 2

Uno dei motivi principali per separare il codice in livelli è organizzare e allineare ogni base di conoscenza con una base di codice .

Ad esempio, se hai questi tre strati

UX
Affari
Accesso ai dati

... quindi hai suddiviso la tua base di conoscenze in questo modo:

Uno sviluppatore UX che comprende HTML e flussi di lavoro e sa come dovrebbero apparire le pagine e cosa fanno. Il suo compito è quello di far apparire le pagine come dovrebbero, mentre si integrano con un livello aziendale che espone solo ciò di cui ha bisogno per portare a termine il lavoro. Se commette un errore in merito alla logica di business (ad esempio, tenta di inserire una data di nascita in un campo nome), il livello aziendale prenderà il suo errore per lui.
Uno sviluppatore del livello aziendale che forse non conosce l'HTML così bene ma ha le conoscenze aziendali su fleek. Sa quale tipo di operazioni sono valide e quando e sa come tradurre i dati forniti dall'utente nel modello dati. Il suo compito è di esporre queste entità e regole aziendali allo sviluppatore UX in un modo che è facile da digerire e difficile da fare in modo non corretto.
Uno sviluppatore del livello dati che comprende il database, che cos'è R / I, come ottenere dati in / out da esso in modo efficiente, ecc. Il suo compito è esporre il modello dati al livello aziendale in un modo che consente un accesso rapido e coerente e garantisce l'integrità durante il salvataggio dei dati.

Anche se la tua squadra è molto piccola, o anche solo una persona, può aiutare a suddividere il lavoro in questo modo in modo che il tuo cervello non debba eseguire così tanti interruttori di contesto quando pensa a un problema. Aiuta anche a sapere dove trovare ogni tipo di logica nel codice base quando devi correggere bug o apportare miglioramenti.

Ovviamente puoi eliminare tutti i livelli, o aggiungerne altri, ma spero che lo farai in linea con una strategia generale di gestione della conoscenza, altrimenti la tua applicazione diventerà molto confusa man mano che cresce.

score 0 · Answer 3

Penso che per le tue intenzioni (lettura / aggiornamento di un database) possa essere usato CQRS (Command Query Responsibility Segregation).

In un tale principio di comando usato per cambiare stato di un oggetto. La query ha utilizzato solo la lettura dal database.