Come progettare BLL in ASP.NET MVC

Question

Come progettare BLL in ASP.NET MVC

#1 da (2 voti)
#2 da (1 voti)

0

Sto provando a progettare una soluzione N-Tier per il mio progetto WebAPI esistente.

Ho un progetto WebAPI in cui, al momento, tutte le logiche di business sono scritte nei controller e la convalida dei dati viene effettuata tramite annotazioni.

Questo sta portando a duplicare il codice tra i controller quando sto tentando di implementare la stessa logica.

Quindi ho pensato di spostare le mie Business Logics in Business Layer. Ma per lo più sto affrontando delle sfide nel restituire le convalide aziendali al controller.

Per E.g ho una porzione di codice nel controller come

//Check if User is adding himself
            if (RequestUser.Email == model.Email)
            {
                return BadRequest("Email", "You cannot add yourself as an User");
            }

Ora, come posso restituire BadRequest dai metodi di Business Class?

E diventa difficile quando la riga successiva del controller è

IdentityResult result = await UserManager.CreateAsync(user);

                if (!result.Succeeded)
                {
                    return result;
                }

Quindi non posso restituire entrambi BadRequest & IdentityResult dallo stesso metodo. Inoltre BadRequest, ModelState non è accessibile nei controller. Ovviamente posso aggiungere System.Web.Mvc in BLL, ma sarebbe una buona idea?

Un'altra cosa che mi piacerebbe sapere è che sto creando dei metodi all'interno dei BLL che stanno prendendo ViewModels che ricevo nei controller. È una buona idea per il progetto esistente? O dovrei creare DTO (come i modelli) in BLL e usare AutoMapper per mappare le proprietà e lasciare che BLL funzioni su DTO invece che passare ViewModels.

Penso che quest'ultimo sarebbe più estensibile, ma richiederebbe più tempo.

Infine, se mi suggerisci di andare con DTO, allora devo cambiare a BLL DTO così come a Model quando introduco nuove proprietà, non è una cattiva idea? Anche il codice viene duplicato qui. Dall'altro lato, a partire da ora, cambio anche tutti i relativi ViewModels (a volte 2-4) (che penso non sia l'approccio giusto) quando aggiungo una nuova proprietà ai Modelli.

Quindi qual è l'approccio giusto?

asp.net-mvc business-logic business-rules layers

posta Krishnandu Sarkar 02.01.2017 - 17:28

fonte

2 risposte

Leggi altre domande sui tag asp.net-mvc business-logic business-rules layers

Come progettare le classi in php nel modello di repository? Modifica temporaneamente lo stato dell'oggetto per salvare il passaggio dei parametri

score 2 · Answer 1

Ci sono molti modi in cui puoi avvicinarti a questo.

restituisce un valore che indica una condizione di errore, come null .
genera un'eccezione.
avvolgi il tuo DTO in una sorta di "forse" oggetto che restituisce sia il tuo DTO che alcune informazioni sullo stato.
Utilizza il modello Unità di lavoro.

L'approccio giusto è quello che soddisfa in modo efficace le tue esigenze specifiche.

score 1 · Answer 2

Sarebbe inappropriato lanciare BadRequest dal livello aziendale in quanto il BL non dovrebbe avere alcuna dipendenza dal livello dell'interfaccia web e in linea di principio non dovrebbe sapere che è eseguito come parte di una richiesta web. La soluzione più semplice consiste nel lanciare un'eccezione di business logic definita al livello BL e quindi gestirla sul livello controller.

Lo strato BL non dovrebbe avere alcuna dipendenza da ViewModel, per lo stesso motivo. Dovresti usare modelli che sono indipendenti da qualsiasi vista specifica nel livello BL. Questi modelli non devono però essere DTO. Potrebbero essere qualsiasi tipo di oggetto commerciale.

È possibile utilizzare la creazione automatica per copiare i dati tra il modello e il modello della vista. Ma dovresti forse considerare se hai bisogno di modelli di visualizzazione, allora? Se il modello di vista sta solo riflettendo il modello 1: 1, non hai davvero bisogno del livello aggiuntivo di modelli di vista. Suggerisco di introdurre i modelli di visualizzazione solo quando ne hai effettivamente bisogno.