Dove si trova l'elaborazione del modulo in un'applicazione MVC?

Question

Dove si trova l'elaborazione del modulo in un'applicazione MVC?

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

5

Ho trovato questa domanda nello stack overflow e ho una domanda su una delle risposte:

In Zend Framework, le forme sono in genere oggetti con decoratori, ma di solito (pensavo) l'elaborazione viene eseguita utilizzando una combinazione di controller e modelli, con l'obiettivo principale di mantenere il controller il più leggero possibile e ogni oggetto responsabile della sua proprio stato.

Una delle risposte dice di usare l'oggetto modulo stesso come luogo per incapsulare i membri di elaborazione dei moduli. È una buona pratica?

Per qualche motivo mi sembra imbarazzante. Ma sembra anche difficile eseguire la maggior parte del lavoro sia nel livello di astrazione del database (Zend_Db_Table / Row) che nel controller. Dov'è il posto migliore per incapsulare l'elaborazione dei moduli? Dovresti creare classi separate per il modulo stesso e un'altra classe per l'elaborazione del modulo (che poi gestisce il DBAL)?

Modifica: qui è un altro post SO che fa una domanda simile, ma l'OP non riceve una risposta completa.

Vogliamo sapere: dove si trova ogni parte della logica di elaborazione del modulo?

design web-development design-patterns

posta Community 25.10.2011 - 23:11

fonte

4 risposte

2

Dipende dal tipo di convalida - quando la logica di convalida fa parte del dominio aziendale, ad es. formato di un numero di previdenza sociale, quindi la convalida deve essere situata nel modello. Se la logica di convalida si applica solo a un modulo specifico, inserire la convalida nel modulo.

Lo fai perché vuoi poter riutilizzare la logica di validazione in più moduli possibili.

risposta data 26.10.2011 - 07:57

fonte

2

Il sempre pertinente "dove diavolo fa la logica di validazione ?!" domanda;).

La risposta è: dipende.

Mi piace applicare il seguente set di regole:

Primo: convalide del livello del database che mi impediscono di inserire dati errati

Secondo: convalide del livello di visualizzazione un po 'più lucide per fornire risposte specifiche al modulo specifico

Terzo: convalide di livello javascript che eseguono la convalida dinamica per salvarle dal fastidio di fare clic su

submit->ohfrickmissedthat->fix->submit->ohfrickmissedthattoo

Ovviamente quanto segui questo set di regole dipende da quanto deve essere utilizzabile la tua applicazione.

risposta data 26.10.2011 - 09:40

fonte

0

se crei un oggetto che è mappato dal tuo modulo e che si associa a una tabella di database, zend ti rende la vita molto più facile a quel punto.

Dovresti processare i moduli a livello di controller o se ha senso in una classe di delegati aziendali. ma sii diverso che non puoi fare anche i livelli. di quanto dovrai passare intorno agli oggetti, ecc. sarà un disastro e difficile da mantenere. Di solito inizio dal controller, se non c'è molta logica aziendale da eseguire.

risposta data 25.10.2011 - 23:42

fonte

Leggi altre domande sui tag design web-development design-patterns

parser simile a SAX: come si chiama questo modello? Trasferimento dati in linguaggio assembly

score 2 · Accepted Answer

La logica di convalida appartiene al database, al modello di dominio e possibilmente il modello di vista.

Penso che molti framework abbiano decoratori / attributi del modello per definire la convalida e visualizzare gli helper per rendere la vista dal modello, inclusa la lucidità della validazione lato client. Quindi prova a lasciare che il framework faccia tutto ciò che funziona per te e concentrati sul Modello.
La logica aziendale appartiene sia al modello (logica dipendente dal dominio) e il controller (logica dipendente dal servizio).

Tendo a pesare quanto più logica possibile nel modello di dominio per mantenere il Controller luminoso, come dici tu. Ma generalmente preferisco non iniettare il servizio dipendenze nel mio livello di dominio, quindi alcuni di quella logica deve capita nel controller.