Che modelli ho? E cos'è un livello?

Prendendo in considerazione questa citazione da la risposta accettata dalla tua domanda originale :

Here's how I see the different layers (note for experienced readers: I've willingly simplified to make it understandable for the OP):

View <==> Controller <==> Business model <==> Data access

E prendendo in considerazione questa risposta da parte mia su una vecchia domanda riguardante il modello di repository , penso che manchi un punto fondamentale per comprendere la stratificazione o l'architettura pulita di un'applicazione ASP.Net MVC.

E il concetto chiave qui è UI è un grande livello . Respiro. Calmati. Ti spiegherò a breve.

Pensa a tutte le regole aziendali della tua applicazione, cosa dovrebbe fare, chi la gestirà. Fatto ? Buono.

Non implementare tutto usando un'interfaccia della riga di comando. Crea un'applicazione console .Net e prova a eseguire tutto ciò che ti serve da quell'applicazione console. Devi aggiungere un esame? Buono. Crea un'entità Esame, un repository ExamRepository, fai in modo che questo repository parli al tuo DAL (che si tratti di un ORM leggero come Dapper o Linq To SQL o Entity Framework o NHibernate, ma rimango con Dapper all'inizio).

Il tuo repository dovrebbe fare per te le tue operazioni CRUD . Non pensare, basta manipolare il DAL per fare cose "di basso livello".

Ora crea un oggetto "business", come un ExamBusiness. Questo oggetto potrebbe avere le regole aziendali implementate, ad esempio "un esame deve sempre avere un nome studente e il nome studente deve contenere almeno 3 caratteri". Il tuo oggetto business chiama il tuo repository per salvare e recuperare i dati.

Ora, una piccola modifica alla tua Applicazione Console: fallo parlare solo al tuo oggetto Business. Niente di più, nient'altro. La tua app per console non dovrebbe comunicare direttamente con il tuo DAL o il tuo repository.

Fatto? Buono. La tua domanda è finita. Le tue regole aziendali sono implementate. Tutto è funzionale. Tranne per un piccolo dettaglio: come il tuo utente interagirà con la tua applicazione.

Immette ASP.Net MVC. O Windows Form. O Console App. O servizio WPF. Ma per tutti gli scopi previsti, continuiamo con ASP.Net MVC qui.

In questo esempio, ASP.Net MVC è solo il livello dell'interfaccia utente . Mostra gli esami agli utenti e consente agli utenti di modificare questi esami in qualche modo. Per rendere le cose più grafiche:

+-----------------+---+-------------+
| UI              | E | ASP.Net MVC |
+-----------------+ n +-------------+
| Business        | t | Another     |
+-----------------+ i | project on  |
| Repository      | t | your .Net   |
+-----------------+ y | solution.   |
| DAL             |   |             |
+-----------------+---+-------------+

Ma per quanto riguarda i miei modelli su ASP.Net MVC? Bene, sono ciò che dovresti mostrare all'utente nelle pagine HTML. Hai sui tuoi oggetti aziendali un'entità chiamata esame. Ma la tua entità dell'Esame ha tutti i campi necessari per essere mostrata all'utente? E le chiavi straniere? Avrai bisogno di un nome studente per mostrare l'esame, ma non hai bisogno del nome per mantenere un esame, hai solo bisogno dell'ID?

Sembra che la denominazione predefinita dei modelli su un'applicazione ASP.Net MVC sia una convenzione scadente. Quello che realmente sono sono ViewModels e non i modelli "reali". Sono ciò di cui hai bisogno per interagire con l'utente, non il minimo necessario per il funzionamento dell'applicazione.

Linee in basso:

1. Il tuo dominio dovrebbe trovarsi su un'altra libreria di classi, puoi farlo disaccoppia l'interfaccia utente dal problema che stai cercando di risolvere;
2. Il livello dell'interfaccia utente è enorme. E dovrebbe essere enorme, dando la sua importanza;
3. L'esempio sopra è basato su Modello di dominio anemico e Clean Architettura. Ci sono avvocati a favore e contro entrambi, ma tu devi sapere che esistono e sono strumenti che puoi usare per far progredire il tuo apprendimento;
4. Non c'è Silver Bullet . Questo post mostra un modo per organizzare la tua soluzione e uno semplice per aiutarti a capire.
5. In questo esempio, le tue Entità sono POCO e i tuoi ViewModels potrebbero essere o meno POCO. Ma la logica aziendale e la convalida devono essere sugli oggetti aziendali, che non hanno stato.

Spero che questo aiuti.

Nel contesto del modello MVC, un modello può essere davvero qualsiasi tipo di oggetto esposto attraverso un'interfaccia utente. Il pattern MVC non riguarda il "tipo" di oggetto che è l'oggetto del modello - piuttosto l'intero punto del modello è che i modelli possono essere qualsiasi cosa. Unico vincolo è che i modelli non devono contenere alcuna presentazione o logica specifica dell'interfaccia utente, poiché questa dovrebbe essere separata nella vista e nelle classi del controllore.

Quindi il modello potrebbe essere collegato a un DAL, ma potresti anche avere un modello che non è connesso a un database o persistente - ad esempio in un gioco. Gli oggetti del modello potrebbero essere entità che rappresentano tabelle di database, potrebbero anche essere astrazioni che incapsulano entità o potrebbero non essere correlate alle entità.

Che tipo di modelli avresti bisogno nel tuo progetto dipende dal tipo di applicazione che stai scrivendo!

I mean they get connected to the database through the DbContext don't they?

Per me questa è la linea rivelatrice del tuo post. Stai usando il framework di entità e sta colorando l'intero approccio.

Ora non sto dicendo che EF è una cosa terribile che non dovresti mai usare .... Ma!

Probabilmente ti aiuterà a pensare a questi problemi se non l'hai usato.

Quindi, al posto di EF immagina di avere oggetti repository che puoi usare per persistere e recuperare i tuoi .. lasciali semplicemente chiamarli 'business class' per ora, esame, problema, sottoprogetto e qualsiasi altra cosa tu abbia

public interface IRepo
{
    Exam GetExamByid(string id);
    List<Exam> GetAllExams();
    void SaveProblem(Problem p);
    ... whatever other methods we need
}

Non ci interessa l'implementazione, semplicemente popola quelle classi con dati dal db in qualche modo. Data Layer, spunta!

Quindi, ora abbiamo un po 'di funzionalità che vogliamo aggiungere all'app, forse è' Grade a completed Exam 'abbiamo scritto il codice che prende i dati da un oggetto Exam completamente compilato e completato come input e restituisce un Oggetto risultato La domanda è dove dovremmo inserire questo codice.

Ci sono un certo numero di risposte.

1. Procedurale: semplicistico. Inserisci il codice sul controller

Possiamo semplicemente avere un controller con un metodo che carica un Exame dal repository, esegue il codice proprio lì e restituisce l'oggetto Result, magari salvandolo di nuovo tramite il repository.

Vantaggi: si accendono le nuove classi, dobbiamo avere il controller e il codice può essere visto come "Controlling", quindi perché no.

Punti negativi: associa la logica all'implementazione dell'app MVC. Se vogliamo una app WPF la prossima settimana, dobbiamo riscrivere alcune cose.

2. Procedurale: ADM, crea classi di servizio

Il prossimo passo avanti, creiamo un nuovo progetto, ExamMarkerService con una classe ExamMarkerService con il codice in esso.

Abbiamo ancora un controller, ma crea semplicemente un'istanza del servizio, lo chiama e restituisce i risultati.

Minuses: più codice Plus: più separazione delle preoccupazioni. Il controller si preoccupava solo di analizzare il messaggio HTTP in arrivo e di inviare una risposta. la classe di servizio ha la logica e può essere inserita in qualsiasi applicazione. Inoltre, è facile passare alla nuova logica più tardi.

3: OOP: il metodo funziona con i dati

Aggiungiamo il codice direttamente a un metodo nella classe Exam. Il controller estrae l'esame dal repository, chiama Exam.Grade () e restituisce il risultato.

Vantaggi: non ci sono classi extra in circolazione Aspetti negativi: può diventare complicato se hai bisogno di più dati di quanti non siano nella classe degli esami.

Livello aziendale, spunta!