Interazione tra controller e modello

Question

Interazione tra controller e modello

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

0

Sono abbastanza nuovo in MVC e sto cercando di comprenderlo meglio. Ci sono infinite informazioni sulla teoria e le responsabilità generali di ogni parte di un'app MVC, che ho letto molto, ma mi trovo costantemente a pensare alla mia implementazione.

Al momento ho la mia configurazione dell'applicazione in cui il mio "Modello" fornisce una serie di metodi che fanno in modo che CRUD funzioni sui dati dell'applicazione. Metodi come add_document(name, path) e update_account(id, code, name, status) A questo punto funziona, ma sembra goffo, in quanto devo effettivamente decidere se voglio scrivere un metodo per aggiornare ogni proprietà di un oggetto modello, o se voglio un metodo che possa gestire l'aggiornamento di qualsiasi proprietà per un dato oggetto. Questi metodi interagiscono tutti con gli oggetti del modello in SQLAlchemy (un toolkit db Python e ORM). Ultimamente ho considerato la possibilità di passare gli oggetti ORM avanti e indietro tra il Modello e il Controller. Il controller modificherà una proprietà, quindi restituirà l'oggetto al modello che gestirà sessioni, commit e condizioni di errore. Anche se questo sembra molto più semplice della scrittura di moltissimi metodi CRUD, sembra anche che rompa la divisione della responsabilità consentendo al Controller di toccare gli oggetti ORM ...

Speravo di ottenere una guida qui. Sono un sacco di operazioni CRUD normali nelle app MVC? È accettabile passare gli oggetti ORM tra il Modello e il Controller - dove il Controller aggiorna solo le proprietà mentre il modello gestisce la sessione e il database funzionano? Sono aperto anche a idee alternative su come separare le responsabilità in modo elegante.

design mvc

posta Patrick D 06.05.2014 - 18:33

fonte

2 risposte

Leggi altre domande sui tag design mvc

Uso commerciale per sistemi embedded Order of Operations Annoyance [duplicato]

score 2 · Answer 1

I metodi del modello non devono essere tutti CRUD. Quello di cui hai probabilmente bisogno è un Livello di servizio.

Il livello di servizio fornisce un'astrazione tra le operazioni di persistenza del database e le operazioni aziendali. Su un lato del livello di servizio, si hanno chiamate ai metodi CRUD e qualsiasi altra risorsa necessaria per soddisfare le richieste di servizio. Dall'altra parte del livello di servizio, hai metodi che eseguono transazioni commerciali:

public bool MoveMoney(guid SourceAccount, guidTargetAccount, SecurityToken token);
public OrderStatus PostOrder(int AccountID, int OrderID);

Questi sono i metodi che il tuo controller chiamerà, non i metodi CRUD.

score 1 · Answer 2

Oh-keeey.

Cosa ti stai sbagliando del modello ..

Devi capire che il "Modello" in MVC non è un oggetto concreto o una classe. Invece è uno dei due livelli principali dell'applicazione:

contiene la "logica aziendale", è dove si trova la maggior parte delle "parti interessanti"
si occupa dell'interfaccia attraverso la quale l'utente può interagire con questa "logica aziendale"

_{Note: as you might already notice, it is perfectly alright to have several presentation layers in parallel. Though it's rare "in the wild".}

Il tuo livello di presentazione (costituito da viste e controllori) interagisce con il livello del modello tramite i servizi . Detti servizi contengono l'interazione tra oggetti dominio e data mapping . Questa parte va sotto il nome di "logica dell'applicazione".

_{For example: if you had a service Library, it manipulate and the exchange between User and Book instance and pass them to different data mappers for persistence. The service doesn't really care how the isValid() method works internally for for the User instance. Neither does it cares where the user is saved, when you call mapper.store(user).}

Gli oggetti del dominio nel livello del modello sono la rappresentazione in codice di "Modello dominio" (per sapere di cosa si tratta, vedi questo libro ). Fondamentalmente, conterranno tutte le regole, le condizioni e le idee aziendali su cui si basa l'applicazione.

E il terzo gruppo principale di strutture all'interno del livello del modello sono in genere mapper di dati. Va la logica della persistenza. È dove il tuo codice CRUD esiste realmente. E parte della logica di persistenza sono i controlli di integrità dei dati. Se, quando si inserisce un nuovo indirizzo e-mail in una tabella, si ottiene un'eccezione relativa alla violazione del vincolo UNIQUE , i mapper dei dati sono dove lo gestisci. Sia che tu lo faccia impostando uno stato di errore sull'oggetto dominio che stai manipolando o kickando / restituendo un codice di errore al servizio, è una tua preferenza (mi piace il precedente approccio).

_{Note: mappers can persist data in any medium that like: sql, nosql, files, remote rest api, /dev/null or crystalline fairy dust. And, if you make sure that the all have same public interface, you can use multiple data mappers on the same domain object. That would let you populate the infamous User instance from sql, cache and session. Simply by passing it to three different mappers with mapper->fetch(user) calls}

Quindi .. dove sono i controllori in tutto questo

I controller, secondo lo schema MVC, hanno una responsabilità molto specifica: alterare lo stato del livello del modello e (in rari casi) la vista corrente. Questo.

I controllori non sanno nulla di CRUD. I controllori non ricevono dati dal livello del modello. I controller non inizializzano o eseguono il rendering delle viste. Niente di tutto ciò.

_{Note: there are edge cases, where in desktop applications (or in situations when, within application's lifetime, there are multiple users interacting with it ... not applicable to web) the controller can observe model layer for changes. And, based on specific change, unlock additional functionality for same user's interaction. I have never seen it in practice.}

Questo significa anche che le tue viste devono essere oggetti reali e non solo modelli stupidi, perché, dal momento che il controllore non sta prelevando alcun dato dal livello del modello, le viste devono decidere quali informazioni hanno bisogno e chiederle da sé.

Queste visualizzazioni completamente implementate di solito destreggiano tra più modelli / layout e oggetti di presentazione . Dall'alta orbita la volontà assomiglia ai servizi, poiché la manipolazione di modelli e oggetti di presentazione assomiglia vagamente all'interazione tra i mappatori di dati e gli oggetti del dominio.

_{i miei 2 centesimi}