oo question - mixing logic logic and business logic

Question

Non sono sicuro se sto usando termini "standard", ma questa è una domanda OO di base che sto cercando di risolvere.

Sto codificando un modulo di Windows. Non voglio la logica nel gestore di eventi del modulo, quindi faccio una chiamata a un oggetto personalizzato da lì.

Nell'oggetto personalizzato, ci sono due gruppi di logica.

1. La logica "controller", che decide cosa deve essere fatto e quando.
2. La logica aziendale effettiva che fa ciò che deve essere fatto (ad esempio un controllo che esegue un'operazione matematica e restituisce risultati, ecc.).

La mia domanda è, l'architettura OO consente di avere entrambi in un singolo oggetto? O è consigliato dividerli in un oggetto "controllore" e in un oggetto "logica aziendale"? C'è uno schema di progettazione a cui dovrei fare riferimento per questo?

Per ora, ho iniziato il percorso della combinazione di questi in un unico oggetto. Questo oggetto ha un metodo "start" che contiene la logica del controller. Questo metodo chiama quindi altri metodi dell'oggetto secondo necessità e alla fine restituisce risultati al chiamante dell'oggetto.

Answer 1

In generale, si dovrebbe probabilmente avere questi in due oggetti diversi, ma su questo c'è un qualificatore. Potrebbe avere senso, se il tuo progetto è abbastanza piccolo e il tuo modello di oggetto non è abbastanza complesso, per avere la funzionalità composta in un unico oggetto; tuttavia, se la tua funzionalità è abbastanza complessa, sarà quasi certamente meglio per te separare il controller e gli oggetti di business. Per lo meno, progettate il sistema con un occhio per separare il controller e gli oggetti di business in un secondo momento, se non li separate completamente ora.

Answer 2

No, non inserisco la logica di business nei controller. Aggiungo un livello di servizio intermedio che viene iniettato nei controller. Lascia che il servizio faccia il lavoro. I controller sono per le richieste di routing e le risposte di marshalling.

L'impostazione della logica in un livello di servizio pulito è "orientata al servizio", anche se non si utilizzano servizi Web o WSDL. Ha il vantaggio aggiuntivo di funzionare ancora se si decide di cambiare le tecnologie di controllo/visualizzazione.

Answer 3

Quello che stai facendo è una forma di architettura "Fat Controller". In questi giorni lo sviluppo del software è in trend verso controller sottili.

OO design è tutto incentrato sul disaccoppiamento. Se interiorizzi solo una cosa sulla programmazione OO, lascia che sia così.

Controllare "Domain-Driven Design Quickly". Questo e-book gratuito è un'introduzione sintetica ai concetti trattati nell'importante libro "Domain-Driven Design" di Eric Evans.

L'apprendimento di questi concetti dovrebbe aiutare a capire come separare la logica di business dal controller o dal livello di servizio.

Answer 4

La risposta alla domanda di progettazione può essere come il seguente scenario: come si progetterà l'applicazione se si dovesse anche fornire un client Web per esso.

Sia l'interfaccia utente di Windows Form che l'interfaccia utente web chiamerebbero le stesse classi e metodi. L'unica differenza, quindi, sarebbe il modo in cui ognuno popola l'interfaccia utente e comunica con gli altri livelli.