Business Objects - Recipienti o funzionali? [chiuso]

StackOverflow https://stackoverflow.com/questions/1794274

Domanda

Dove lavoro, siamo andati avanti e indietro su questo tema un certo numero di volte e alla ricerca di un controllo di integrità. Ecco la domanda:. Nel caso Business Objects essere contenitori di dati (più come DTOs) o dovrebbero anche contenere la logica in grado di eseguire alcune funzionalità su tale oggetto

Esempio - Prendete un oggetto cliente, contiene probabilmente alcune proprietà comuni (nome, l'ID, ecc), dovrebbe quell'oggetto cliente anche includere funzioni (Save, Calc, ecc.)

?

Una linea di ragionamento dice separare l'oggetto dalla funzionalità (solo principal responsabilità) e mettere la funzionalità in uno strato Business Logic o un oggetto.

L'altra linea di ragionamento, dice, no, se ho un oggetto cliente voglio solo chiamare Customer.Save e da fare con esso. Perché ho bisogno di sapere su come salvare un cliente se sto consumando l'oggetto?

Le nostre ultime due progetti hanno avuto gli oggetti separati dalla funzionalità, ma il dibattito è stata sollevata di nuovo su un nuovo progetto. Che ha più senso?

Modifica

Questi risultati sono molto simili ai nostri dibattiti. Un voto a una parte o dall'altra cambia completamente direzione. Qualcun altro vuole aggiungere i loro 2 centesimi?

Modifica

Benche 'il campionamento risposta è piccola, sembra che la maggior parte crede che la funzionalità in un oggetto di business è accettabile fintanto che è semplice, ma la persistenza è nella posizione migliore in una classe / livello separato. Daremo a questo una prova. Grazie per l'input di tutti ...

È stato utile?

Soluzione

Gli oggetti sono stato e il comportamento insieme. Se un oggetto ha un comportamento sensibile (per esempio, calcolare l'età di una persona dalla loro data di nascita, o una tassa totale per una fattura), con tutti i mezzi aggiungerlo. Gli oggetti business che non sono altro che DTOs sono definiti un "modello di dominio anemico". Io non credo che sia un requisito di progettazione.

La persistenza è un particolare tipo di comportamento. Quello che sto chiamando "sensibili" è un comportamento aziendale. Un oggetto di business non ha bisogno di sapere che è persistente. Direi che un DAO può mantenere la persistenza separato dal comportamento delle imprese. Non metto "salva" nella categoria "sensibili".

Altri suggerimenti

oggetti commerciali può avere funzionalità di business .

La persistenza non è una funzionalità di business , ma è la realizzazione tecnica.

Per farla breve:

  1. Salva / aggiornamento / eliminazione / Trova etc -. Tenere lontano dagli oggetti di business in uno strato di persistenza
  2. CalculateSalary, ApplyDiscount ecc sono i metodi di business correlati e può essere:
    1. metodi degli oggetti di business (in modo BO è autonomo rappresentazione di entità) o;
    2. servizi separati attuazione particolare funzionalità (in modo BOs agiscono più come DTOs).

Per quanto riguarda il punto 2.
Devo dire che l'approccio 2.1 tende a rendere le BOs troppo gonfio e violare SRP . Mentre 2.2 introduce una maggiore manutenzione complessità .

Io di solito bilancio tra 2.1 e 2.2 in modo che ho messo le cose banali relative ai dati in Business Objects e creare servizi per un po 'scenarious più complessa (se ci sono più di 4 righe di codice - rendere un servizio).

Questo sposta il paradigma di Business Objects per essere più Transfer Data Objects, invece.

Ma tutto questo rende più facile del progetto per sviluppare, testare e mantenere.

La risposta è la stessa, indipendentemente dalla piattaforma o linguaggio. La chiave di questa questione è se un oggetto deve essere in grado di essere autonoma o se è meglio per un determinato comportamento da diffondere tra gli oggetti con più focalizzata responsabilità .

Per ogni classe la risposta potrebbe essere diversa. Finiamo con uno spettro lungo la quale possiamo collocare le classi basate sul Densità di responsabilità . 

                          (Level of responsibility for behavior)
         Autonomy - - - - - - - - - - - - - - - - - - - Dependence  
      High
  C      -   <<GOD object>>                            <<Spaghetti code>>
  l      -
  a      -  
  s      -                                      
  s      -                 
         -                        
  s      -  
  i      -  
  z      -
  e      -  <<Template>>                                <<Framework>>
       low

Diciamo che favoriscono lasciando che la classe effettuare tutti i comportamenti per sé, o come molti come si può. Partendo dal lato sinistro di questo grafico, quando si effettua la classe più autonoma, la dimensione della classe crescerà meno che continuamente refactoring per renderlo più generico. Questo porta ad un modello . Se non refactoring è fatto, il temdency è per la classe per diventare più " god-like ", perché se c'è qualche comportamento di cui ha bisogno, si ha un metodo per questo. Il numero di campi e metodi crescere e presto diventano sia ingestibile e inevitabile. Dal momento che la classe fa già tanto, programmatori preferiscono aggiungere alla mostruosità che cercare di mettere lo distingue e tagliare il nodo gordiano.

La parte destra del grafico ha classi che dipendono da altre classi in larga misura. Se il livello di dipendenza è alta ma la classe individuale è di piccole dimensioni, che è un segno di un quadro ; ogni classe non fa molto e richiede un sacco di classi dipendenti per compiere qualche funzione. D'altra parte, una classe altamente dipendente che ha anche una grande quantità di codice è un segno che la classe è piena di Spaghetti .

La chiave di questa domanda è quello di determinare dove si sente più a suo agio sul grafico. In ogni caso, le singole classi finiscono sparsi sul grafico a meno che non viene applicato un principio organizzativo, che è come è possibile ottenere i risultati di modello o quadro .

Avendo appena scritto che, direi che c'è una correlazione tra le dimensioni di classe e grado di organizzazione. Robert C. Martin (o "Uncle Bob") copre terra simile con le dipendenze dei pacchetti nel suo articolo molto approfondito su design Principles and design Patterns . JDepend è un'implementazione delle idee dietro il grafico a pagina 26 e complementi strumenti di analisi statica come Checkstyle e PMD .

Credo che ha più senso per gli oggetti di business per saper "gestire" se stessi, poi per mettere tale onere in altre parti del sistema. Nel tuo esempio, il posto più logico per affrontare con il modo di "salvare" i dati dei clienti sarebbero stati, per me, nell'oggetto cliente.

Questo può essere perché considero il database di essere il "contenitore di dati", quindi sono a favore di "oggetti di business" è il livello più alto che protegge il contenitore di dati da un accesso diretto e applica "regole aziendali" standard su come si accede che i dati / manipolato.

Abbiamo utilizzato quadro CSLA di Rocky Lhotka per anni e amiamo il modo in cui è stato progettato. In tale contesto tutte le funzionalità è contenuta negli oggetti. Mentre posso vedere il valore di separting logica fuori, non credo che passeremo da questa filosofia in qualunque momento presto.

Gli oggetti business dovrebbe essere di circa l'incapsulamento dei dati e dei comportamenti associati dell'entità commerciale modellata da quell'oggetto. Pensate a come questo: uno dei principi fondamentali della programmazione orientata agli oggetti è l'incapsulamento dei dati e comportamenti associati su tali dati.

La persistenza non è un comportamento dell'oggetto modellato. Trovo sviluppo procede più agevolmente se gli oggetti di business sono la persistenza ignornant. Lo sviluppo di nuovo codice e unità di testare il nuovo codice accadere più rapidamente e più agevole se gli oggetti di business non sono specificamente legati all'impianto idraulico sottostante. Questo è perché posso prendere in giro quegli aspetti e dimenticare di dover passare attraverso i cerchi per arrivare alla base di dati, ecc mio test di unità eseguiranno più velocemente (un vantaggio enorme se si dispone di migliaia di test automatizzati che vengono eseguiti con ogni generazione) e I avrà meno stress, perché non avrò le prove in mancanza a causa di problemi di connessione al database (ottimo se si lavora spesso non in linea o in remoto e non si può sempre accedere al database e oh, a proposito, quegli aspetti (database connettività, ecc) dovrebbero da provare altrove!).

  

L'altra linea di ragionamento, dice, no, se ho un oggetto cliente voglio solo chiamare Customer.Save e da fare con esso. Perché ho bisogno di sapere su come salvare un cliente se sto consumando l'oggetto?

Sapendo che Customer ha un metodo Save è già sapere come salvare un oggetto cliente. Non hai evitato il problema inserendo la logica nel vostro oggetto di business. Invece, hai fatto la vostra base di codice più strettamente accoppiati e quindi più difficile da mantenere e test. Spingere fuori la responsabilità della persistenza dell'oggetto a qualcun altro.

Gli oggetti commerciali, come vengono chiamati, devono ovviamente coutain la propria logica di business, la dinamica della logica di business tra il dominio essere al livello di servizio.

D'altra parte, potrebbe la BO essere un contenitore di dati (DTO?) Composizione e metodi; il che significa BO sono pura functionnal? Questo potrebbe evitare tutte le conversioni tra Bo e DTO.

In un'architettura MVC,

Si può dire che Modello contiene oggetti di business.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top