Come dovrei progettare un design OO corretto in caso di un'operazione a livello di logica aziendale

2

Modifica

Forse dovrei fare la domanda in un modo diverso. alla luce del commento di ammoQ, mi rendo conto che ho fatto qualcosa di simile a suggerire che è una specie di correzione e va bene per me.

Ma voglio ancora imparare per il futuro, così se sviluppo un nuovo codice per operazioni simili a questo, posso progettarlo correttamente dall'inizio.

Quindi, se ho le seguenti caratteristiche:

  • L'input rilevante è composto da dati che sono collegati a
    diversi oggetti di business diversi

  • Tutti i dati di input sono convalidati e confrontati

  • I tentativi vengono fatti per inserire i dati nel DB

  • Tutto questo è solo una singola operazione da parte di Business Prospective, il che significa che tutto il controllo incrociato e le convalide sono solo effetti collaterali.

Non riesco a pensare in nessun altro modo se non a una specie di tipo Operatore / Coordinatore di Oggetto che attiva l'intera procedura, ma poi cado in un tipo di codice di Decomposizione Funzionale. quindi c'è un modo migliore per farlo?

Domanda originale

Nel nostro sistema abbiamo molte operazioni complesse che coinvolgono molte convalide e attività di DB.

Una delle principali funzionalità di Business avrebbe potuto essere migliorata. In breve, non c'erano separazioni di livelli e il codice funzionava solo dallo scenario in cui era stato inizialmente progettato e ora c'erano più scenari (come richieste da un'API o da altri dispositivi)

Quindi ho dovuto riprogettare.

Mi sono ritrovato a spostare tutto il codice DB in oggetti che funzionano come oggetti Business to DB e ho inserito tutta la logica di business in un tipo di operatore di una classe, che ho implementato in questo modo:

Per prima cosa, ho creato un oggetto che contiene tutte le informazioni necessarie per l'operazione, chiamiamolo InformationObject.

Poi ho creato un oggetto OperatorObject che prenderà l'oggetto InformationObject come parametro e agirà su di esso.

L'OperatorObject deve attivare oggetti diversi e convalidare o verificare l'esistenza o qualsiasi scenario in cui la logica aziendale è compromessa e quindi eseguire l'operazione in base alle informazioni su InformationObject.

Quindi la mia domanda è: questo tipo di implementazione è corretta?

PS, questo operatore funziona solo su una singola operazione Business-wise.

    
posta Mithir 24.11.2011 - 07:50
fonte

1 risposta

0

Se vuoi ristrutturare il tuo codice e aspettarti ulteriori miglioramenti, applicheresti la progettazione basata sul dominio con un approccio a N livelli.
microsoft architectue

L'approccio applicato non è orientato agli oggetti, ma stile procedurale , si utilizzano classi di informazioni per mantenere i dati e tutti le logiche di business sono in un'altra classe. Va bene se non stai seguendo rigorosamente il design OOP, ma è consigliabile avere sia dati che comportamenti in una singola classe in modo che tu possa elaborare con altre funzioni di OOP come l'incapsulamento, il polimorfismo ecc.

    
risposta data 10.12.2011 - 20:07
fonte

Leggi altre domande sui tag