MVC e regola aziendale

Naviga le tue risposte
4

Ho bisogno di sapere dove nel MVC dovrei applicare la regola aziendale.

Immagina la situazione: ho una scuola e ho bisogno di generare un calendario di lezioni per insegnanti. Ogni insegnante ha una materia scolastica ed è disponibile solo in determinati orari. Devo generare questo calendario in modo tale che gli insegnanti possano eseguire senza conflitti temporali.

Ecco le mie domande:

  1. Di quale parte di MVC l'insegnante dovrebbe far parte? Tenendo presente che i tuoi dati di timing sono memorizzati esternamente (come un database SQL o un XML), dovrebbe essere un modello, corretto?
  2. Ora, dove nel MVC dovrebbe essere sviluppata la regola aziendale che compilerà il calendario? Ti piace il controller o una libreria?
  3. Questi dati potrebbero essere elaborati direttamente nel Modello o, forse, un Modello specifico per lavorare con altri Modelli?

Ora un po 'della mia visione: (per favore, correggimi se sbaglio)

  1. I dati degli insegnanti dovrebbero essere gestiti da un modello. In modo che, ad esempio, potessi avere il tempo a disposizione di lui e della sua materia scolastica. Quindi, Teacher is Model.
  2. La compilazione del calendario potrebbe essere eseguita in un controller o in una libreria. Domanda: ma i controller devono essere correlati ai percorsi e alle librerie di un'API?
posta David Rodrigues 08.07.2014 - 18:06
fonte

3 risposte

5

Nel contesto del pattern MVC, i componenti Controller e View riguardano solo le interazioni dell'utente (il controller reagisce alle richieste e la vista presenta l'interfaccia utente). Tutti gli altri codici, inclusa la business logic e l'accesso al database, vanno nel componente Model.

Dato che il Modello di solito è abbastanza grande, dovrebbe avere una struttura interna aggiuntiva, ma che va oltre lo scopo del pattern MVC.
Comunemente, il modello è strutturato in livelli, con un livello per la logica aziendale, un livello separato per l'accesso al database e, eventualmente, altri livelli.

Come nota a margine, non fare troppo del fatto che le librerie abbiano le API. L'API di una libreria è per definizione l'insieme di classi e funzioni che la biblioteca fornisce al mondo esterno per il loro utilizzo. Ogni libreria ha un'API, ma diventa importante solo quando è necessario fornire la compatibilità con le versioni precedenti del codice che è stato scritto per utilizzare versioni precedenti della libreria. Questo di solito non è necessario per le librerie che vengono utilizzate solo da un'applicazione.

    
risposta data 08.07.2014 - 18:45
fonte
0

Le regole aziendali sono una responsabilità pervasiva dell'applicazione. La vista dovrebbe impedire la creazione di programmi in conflitto non consentendo loro come opzione; il controllore dovrebbe identificare le interazioni e impedire che si formino in conflitto. Il modello dovrebbe impedire la memorizzazione di programmi in conflitto.

Mentre hai una regola generale ("nessun conflitto"), la regola si manifesta in sotto-regole nei vari domini che influenzano o sono influenzati dalla regola.

    
risposta data 08.07.2014 - 19:48
fonte
0

Il modello sono i tuoi dati: insegnanti e classi.

Il tuo controller, tra le altre cose, compone i dati del modello in modo tale che la Vista possa facilmente digerirli e visualizzarli. La composizione di un ViewModel è un buon modo per farlo se la logica alla base della visualizzazione dei dati è complessa.

La tua vista prende i dati che il controllore ha preparato per esso, se ce ne sono, e li rende.

È popolare astrarre il modello (in livelli) e gestire la logica aziendale dietro il velo.

    
risposta data 08.07.2014 - 20:27
fonte

Leggi altre domande sui tag

Esiste un modo per utilizzare le tecniche RAII in COM? Perché l'oggetto DbContext non deve essere indirizzato in Service Layer?