Condivisione della logica del codice tra i controller, attraverso il livello Model?

2

Come originariamente concepivo il mio livello Model, si supponeva che fosse in grado di contenere dati e nessun codice. Ricevo DTO dai servizi web, sono mappati negli oggetti del mio modello. Questi oggetti del modello di solito finiscono per essere composti o specializzati in oggetti ViewModel. Nella maggior parte dei casi, un controller chiama alcuni servizi Web e crea un oggetto ViewModel che consegna alla vista. In realtà, a volte devo creare una classe nel livello Model, accanto ai miei oggetti dati, che mantengono una certa logica aziendale. Il motivo è che questa logica è condivisa tra i controller. Quando alcuni codici non sono specifici e non richiedono molta «configurazione» creo dei metodi statici brevi, quello che capisco è quello che comunemente si chiama «aiutanti». Ho creato una cartella «Helpers» allo stesso livello delle cartelle «Controllers», «Views», «Models», «ViewModels». È giusto in termini di struttura del progetto? Non so.

Ora succede che ho bisogno di condividere del codice, che richiede qualche configurazione, tra i controller. Ad esempio, a un certo punto, il codice aziendale deve chiamare un servizio web con vari parametri relativi al calcolo in corso. Tra questi parametri c'è una chiave di sessione. Pertanto, questa chiave di sessione deve essere configurata sull'oggetto business prima che inizi il trattamento.

Dopo che il codice aziendale ha fatto il suo lavoro, il controllore consegna il modello a una vista. Questo modello, pur non variando in termini di classe di oggetti, potrebbe utilizzare i dati creati da vari oggetti di business. Nel mio caso, ho una vista parziale che mostra un albero. I dati dell'albero possono provenire da diversi servizi web che richiedono input diversi e producono risultati diversi. Solo il modello risultante ha un vincolo di tipo di oggetto.

All'inizio avevo questo ...

IlcontrollerharecuperatoidatidalservizioWebequindihacreatounastrutturaadalberoconqualchetrattamento.QuestastrutturaèstataconsegnataaunoggettoViewModel,cheèstatopoiconsegnatoallavista.

Mapoi,poichéavevobisognodiaccederealcodicechecostruivalastrutturaadalberodaunaltrocontroller,hoisolatoquestocodiceinquellocheistintivamentechiamavoun«costruttore».Questooggettodovevaessereinizializzatodaqualsiasicontrollercheneavevabisogno,primadichiamareilmetodoBuildHierarchy().Ora,hobisognodicreareunasecondalogicadicostruzionedeglialberi,basatasualtridatidiunaltroservizioweb.Madesideroutilizzarelastessavistapervisualizzarequeidati.

Daunpuntodivistapiùgenerale,eccocomeattualmenteimmaginolastrutturadiuntalecodice...

Quindi ho due domande:

  • Ho letto un po 'del pattern Builder e capisco che non dovrei chiamare il mio oggetto un «costruttore» e che questo modello non è adatto a questo caso. C'è qualche schema corrispondente a ciò che desidero realizzare?
  • Nella mia struttura del progetto, dove dovrei mettere effettivamente quegli oggetti business? Ho ragione a metterli nel livello Model, o dovrebbe essere altrove?
posta Yugo Amaryl 26.02.2015 - 11:41
fonte

2 risposte

2

Penso che manchi 1 o forse 2 livelli nel tuo design, motivo per cui non sei sicuro di dove mettere la logica di business o il codice 'builder'. Dovresti prendere in considerazione l'aggiunta di un servizio e possibilmente di un livello di repository.

Il livello di servizio è un livello che si interfaccia tra i controller e il modello / repository. Può contenere logica di business o può essere solo un sottile livello API. Il livello del repository è responsabile della restituzione degli oggetti del modello ai servizi o ai controller (penso che questo sia il concetto di costruttore che hai menzionato).

Anche se i livelli extra aggiungono complessità, preferisco separare le responsabilità - di solito è più facile testare in questo modo e in seguito si hanno meno problemi quando si desidera sostituire l'interfaccia utente, aggiungere un'interfaccia dei servizi Web, ecc.

    
risposta data 26.02.2015 - 17:36
fonte
1

Quindi nel mondo ideale il tuo controllore non dovrebbe contenere alcuna logica di business o oggetti di business. Questi dovrebbero essere posizionati completamente nel livello del tuo modello di dominio. Facendo riferimento a "Patterns of Enterprise Application Architecture" di Martin Fowler, il controller è anche parte del livello di presentazione, quindi è responsabile solo di passare i dati di input ai propri oggetti di business e restituire la vista.

Non sono sicuro di ciò che stai effettivamente facendo con il tuo costruttore, ma se ho capito bene dovresti pensare al modello di fabbrica. Una factory decide in base alla logica in fabbrica come deve essere costruito un oggetto, a partire da quale classe utilizzare, ma anche quali dipendenze iniettare (che potrebbero riguardare la configurazione).

    
risposta data 26.02.2015 - 16:36
fonte

Leggi altre domande sui tag