Livello logico aziendale completamente separato da MVC

Question

Livello logico aziendale completamente separato da MVC

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

4

Al momento stiamo effettuando il refactoring dei nostri metodi di controller nell'applicazione ASP.NET MVC.

All'inizio abbiamo separato il livello di accesso ai dati (il nostro obiettivo era rimuovere completamente LINQ dai controllori). Ora stiamo pensando ad un altro passo: come creare un livello di logica aziendale per ridurre il numero di linee e la logica nel controller. Attualmente abbiamo qualcosa di simile a questo:

public ActionResult CustomerProjects(some parameters)
{
    var collectionOfSomeType = this.CustomerRepository.GetSomeData();
    var anothercollection = this.ProjectsRepository.GetAnotherData(collectionOfSomeType);

    var viewModel = CreateSomeViewModel(anotherCollection);

    return View("Index", viewModel);
}

Ovviamente è solo un esempio con quattro linee di codice. Abbiamo alcuni metodi che sono più grandi (ma ancora IMO non così male). Abbiamo iniettato le nostre classi di helper attraverso il contenitore IoC, qui si trova una logica più complessa. Ma ora vorremmo rimuovere anche quelle parti.

Vale la pena del nostro tempo per creare un altro livello che sarebbe la nostra "ultima porta" prima dei controller? Il risultato finale sarebbe:

public ActionResult CustomerProjects(some parameters)
{
    var viewModel = someSource.PrepareCustomerProjectsViewModel(params);

    return View("Index", viewModel);
}

Che ne pensi?

design architecture business-logic mvc

posta hugerth 02.07.2014 - 15:06

fonte

4 risposte

1

È una vecchia discussione, ma vorrei aggiungere il seguito per aggiungere BusinessLogic o Management Layer:

Ti aiuterà a rimuovere il codice ridondante come la trasformazione dell'oggetto e il controllo obbligatorio delle regole.
Renderà il codice riutilizzabile e ti aiuterà in situazioni come: devi fornire gli stessi dati in API Web e Metodo di azione con Visualizza o altra applicazione.
Sarà molto utile se ti piace applicare la cache dei dati in futuro.
Renderà il tuo codice facile da testare.

risposta data 12.07.2018 - 15:02

fonte

0

La mia responsabilità preferita per oggetto:

Il controller gestisce la costruzione di viewmodel / viewbag.

La logica non correlata al rendering della pagina viene spedita al BL.

Quindi personalmente comporre il viewmodel all'interno del controller e non creare un livello separato. Il livello che dovresti creare per comporre il modello, come lo chiameresti? Il livello Controller?

risposta data 02.07.2014 - 16:02

fonte

-2

Non mi sembra che questi livelli siano veramente separati a meno che non siano completamente diverse applicazioni.

Sebbene l'idea di classi separate come BL e DAL ecc suona bene, penso piuttosto che l'interfaccia utente dovrebbe gestire solo le funzioni dell'interfaccia utente e ricevere dal BL solo stringhe e numeri in un ordine previsto da passare nei controlli appropriati.

Il BL può ricevere petizioni dall'interfaccia utente, ma penso che queste possano essere passate direttamente al DAL se sono solo recuperi e dopo aver modificato l'interfaccia utente puoi inviare solo le stringhe e i numeri modificati alla BL per il reinserimento al DAL . Funzionando in questo modo il DAL sarebbe solo dati e il linguaggio linguaggio transazione solo.
Il BL può quindi lavorare con le informazioni richieste per convalidarle e formattarle come nuove stringhe con la corretta digitazione dei dati, ad esempio il numero di telefono dal DAL passa al BL come una stringa di numeri e il BL lo riformatta nel formato (AreaCode) settore-numero.
Qualsiasi altra formattazione come a colori, caratteri e simili avviene nell'interfaccia utente. La BL sarebbe l'unica app che si occupa di classi logiche e l'app dell'interfaccia utente avrebbe solo bisogno di classi e oggetti di presentazione. Il DAL deve solo eseguire transazioni.

Ciò rende possibile realizzare programmi veramente modulari in cui UI, BL e DAL sono indipendenti. È un modo per offrire ai clienti opzioni per acquistare app da sviluppatori come l'acquisto di parti di automobili personalizzate. È possibile acquistare le parti delle prestazioni (BL) da una società e le divise per il corpo da un'altra società e si uniranno tutte insieme.

risposta data 12.11.2014 - 22:13

fonte

Leggi altre domande sui tag design architecture business-logic mvc

Voglio davvero un Enum dinamico o qualcos'altro? Meglio il caching? Una Struct? Termine formale per il web-ify un pezzo di software o programma esistente o un modulo? [chiuso]

score 7 · Accepted Answer

Per me non c'è alcuna domanda a cui rispondere qui, dovresti sempre cercare di separare il più possibile i componenti.

Al minimo, per ogni nuovo progetto che creo, faccio esattamente i seguenti passi:

1) Crea una soluzione vuota per lo studio visivo
2) Aggiungi un progetto MVC ad esso
3) Aggiungi una libreria di classi ad essa chiamata livello aziendale
4) Aggiungi una libreria di classi ad essa chiamata Livello dati

In questo modo segui i buoni principi del design n-Tier. Aggiungi a questo una qualche forma di AOP (ad esempio post-sharp o attributi MVC) per gestire tutti gli elementi che tagliano trasversalmente i livelli e hai una buona architettura solida da cui lavorare.

NO RAW I dati del tuo livello dati dovrebbero mai essere inseriti nel tuo livello di presentazione (l'App MVC), tutto dovrebbe essere combinato e appiattito nel tuo livello aziendale.

Il livello aziendale deve gestire solo oggetti DTO tra sé e la presentazione, con dati non elaborati che introduce dal livello dati e applica anche varie regole specifiche per il dominio dell'applicazione.

Prima con il codice EF e con i pacchetti Nu-get come l'auto-mapper, tutto ciò è incredibilmente facile in questi giorni.

Usa EF nel tuo DAL per ottenere i tuoi dati usando Linq, ADO o qualsiasi altra cosa ti serva.

Utilizza l'auto-mapper per trasformare i dati in DTO da passare al livello aziendale, quindi fai tutto il lavoro che ti serve prima di usare finalmente il mappatore automatico per passare il DTO risultante alla tua presentazione.

Anche se NON stai usando MVC, l'adozione di questa strategia è vincente / vincente, anche per WPF, Webform, Winform e molto altro.

Se lo fai correttamente, la porzione MVC diventa essenzialmente un'esposizione cerebrale di ciò che sta facendo il livello aziendale, e la facilità con cui puoi rimuovere la tua app MVC e inserire un'altra UI nella sua posizione è spaventosamente semplice.

Aggiornamento 14/11/2014

Dopo aver letto il commento più recente aggiunto a questo thread, ho ritenuto che aggiungere questa parte aggiuntiva alla mia risposta fosse giustificato.

La buona architettura è molto più di un semplice "Pretty Code".

Se ottieni un'architettura sbagliata, può essere la differenza tra schiantarsi e bruciare e volare in alto in un tripudio di gloria.

Ho fatto I.T & Lo sviluppo del software in una forma o nell'altra ora dal 1979 circa, e credetemi, ho visto la mia giusta dose di fallimenti e successi in quel periodo.

Quando ho iniziato, ed ero ancora bagnato dietro le orecchie, Object Oriented Programming non era nemmeno una cosa, hai concentrato TUTTO in un unico file sorgente, poi lo hai eseguito attraverso un compilatore, quindi un linker senza alcun tipo di Elementi della GUI per aiutarti.

Alcuni dei codici che ho scritto durante questi periodi erano incredibilmente disordinati, inefficienti e completamente orribili. Quando sono cresciuto, e ho imparato, ho iniziato a capire perché questo tipo di codice ha causato i problemi, mentre scrivere un codice di facile lettura è certamente un'abilità importante, è anche molto importante assicurarsi che la tua area sia anche minimo e segue standard di buon livello.

Ho visto tanti grandi progetti fallire (o almeno lottare molto) nel corso degli anni, e ogni volta che è stato a causa di scelte sbagliate fatte a livello di progettazione architettonica, non posso sottolineare quanto sia importante è quello di ottenere il design e i piani prima ancora di toccare una sola riga di codice.

E mentre sono in argomento, i generatori di codice sono altrettanto pericolosi. Se il tuo generatore di codice crea codice da modelli che controlli TU, allora armi grandiose, ma SE dipendi da modelli, in cui non hai il controllo su come viene generato l'output, allora stai chiedendo dei problemi. Visual Studio è un ottimo strumento e straordinario per la creazione di soluzioni veloci, ma assicurati di conoscere ESATTAMENTE ciò che sta creando dietro le quinte quando fai clic su quel pulsante per fare qualcosa.

Se mi capita di sviluppare una biblioteca, l'ultima cosa che voglio fare è scavare nelle fonti per dirmi come funziona, dipendo dall'architetto che l'ha progettata, per guidarmi, facendo scelte logiche, che sono formate da una conoscenza di grandi solide pratiche di software art.

Semplicemente non mi fiderei di nulla che abbia trasmesso corde e valori discreti come se fossero caramelle durante una festa di Natale, perché ... beh, come posso essere sicuro di quale sia il tipo e la responsabilità della variabile / proprietà / metodo è.

Chi ti fiderebbe di più per comprare una casa? Una società professionale che ha assunto un architetto per sondare, pianificare e progettare una serie completa di piani, che un team di professionisti di Costruttori, Roofers, Plasterers ha poi lavorato come una squadra per implementare, o il ragazzo che vive alla fine della tua strada chi lavora nel settore edile e conosce una cosa o due sulla costruzione di case?

So quale sarà la mia scelta.