Quanta logica aziendale deve contenere gli oggetti Value?

Question

Un mentore che rispetto suggerisce che un semplice bean è una perdita di tempo - che gli oggetti di valore 'DEVE' contengano una logica aziendale per essere utili.

Un altro afferma che tale codice è difficile da mantenere e che tutta la logica aziendale deve essere esternalizzata.

Mi rendo conto che questa domanda è soggettiva. Chiedere comunque: vuoi conoscere le risposte da più prospettive.

Answer 1

Dovresti chiamarli Transfer Objects o Oggetti di trasferimento dati (DTO) .

In precedenza questo stesso modello j2ee era chiamato 'oggetto valore' ma hanno cambiato il nome perché era confuso con questo

http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html

Per rispondere alla tua domanda, aggiungerei solo una logica minima ai miei DTO, logica necessaria per motivi di visualizzazione.

Ancora meglio, se stiamo parlando di un'applicazione web basata su database, andrei oltre i modelli j2ee di base e utilizzerei Hibernate o API Java Persistence per creare un modello di dominio che supporti il ??caricamento lazy di relazioni e usalo nella vista.

Guarda la Apri sessione in vista .

In questo modo, non è necessario programmare una serie di DTO e hai tutte le logiche aziendali disponibili da utilizzare nelle tue visualizzazioni / controller ecc.

Answer 2

L'idea di mettere insieme dati e logica aziendale è di promuovere l'incapsulamento e di esporre il minor stato interno possibile ad altri oggetti. In questo modo, i clienti possono fare affidamento su un'interfaccia piuttosto che su un'implementazione. Vedi il " Tell, Don't Ask " e il Legge di Demetra . L'incapsulamento semplifica la comprensione degli stati in cui possono trovarsi i dati, la lettura del codice più semplice, il disaccoppiamento delle classi e generalmente il test dell'unità in genere.

L'esternalizzazione della logica aziendale (generalmente in "classi di servizio" o "gestore") pone domande come "dove vengono utilizzati questi dati?" e " in quali stati può trovarsi? " molto più difficile rispondere. È anche un modo di pensare procedurale, racchiuso in un oggetto. Ciò può portare a un modello di dominio anemico .

L'esternalizzazione del comportamento non è sempre negativa. Ad esempio, un livello di servizio potrebbe orchestrare oggetti di dominio, ma senza assumersi le loro responsabilità di manipolazione dello stato. Oppure, quando fai principalmente letture / scritture su un DB che si associa perfettamente ai moduli di input, forse non hai bisogno di un modello di dominio - o del sovraccarico di mappatura relazionale / oggetto doloroso che comporta -

Gli oggetti di trasferimento spesso servono per separare i livelli architettonici l'uno dall'altro (o da un sistema esterno) fornendo le informazioni minime sullo stato necessarie al livello chiamante, senza esporre alcuna logica aziendale.

Questo può essere utile, ad esempio quando si preparano le informazioni per la vista: basta dare alla vista le informazioni di cui ha bisogno e nient'altro, in modo che possa concentrarsi su come per visualizzare le informazioni, piuttosto di quali informazioni visualizzare. Ad esempio, il TO potrebbe essere un'aggregazione di diverse fonti di dati.

Un vantaggio è che le tue viste e i tuoi oggetti di dominio sono disaccoppiati. L'uso degli oggetti del tuo dominio nei JSP può rendere più difficile il refactoring del tuo dominio e promuove l'uso indiscriminato di getter e setter (interrompendo quindi l'incapsulamento).

Tuttavia, c'è anche un sovraccarico associato con molti oggetti di trasferimento e spesso anche molti duplicati. Alcuni progetti a cui ho partecipato finiscono con i TO che sostanzialmente rispecchiano altri oggetti di dominio (che considero un anti-pattern).

Answer 3

Dipende.

ops, ho appena lanciato un cliché?

La domanda di base da porre per progettare un oggetto è: la logica che governa i dati dell'oggetto sarà diversa o uguale quando usata / consumata da altri oggetti?

Se aree di utilizzo diverse richiedono logica diversa, esternalizzarla. Se è lo stesso, indipendentemente da dove si sposta l'oggetto, posizionalo insieme alla classe.

Answer 4

La mia preferenza personale è quella di inserire tutte le logiche aziendali nel modello di dominio stesso, ovvero nel "vero" oggetti di dominio. Pertanto, quando vengono creati oggetti di trasferimento dati, questi sono per lo più solo una rappresentazione di stato (immutabile) di oggetti di dominio e quindi non contengono alcuna logica aziendale. Tuttavia, possono contenere metodi per la clonazione e il confronto, ma il contenuto del codice della logica aziendale rimane negli oggetti dominio.

Answer 5

Cosa ha detto Korros.

Valore oggetto: = un piccolo oggetto semplice, come denaro o un intervallo di date, la cui uguaglianza non si basa sull'identità.

DTO: = Un oggetto che trasporta dati tra i processi al fine di ridurre il numero di chiamate al metodo.

Queste sono le definizioni proposte da Martin Fowler e vorrei renderle popolari.

Answer 6

Sono d'accordo con Panagiotis: la sessione aperta nel modello di visualizzazione è molto meglio dell'uso dei DTO. In altre parole, ho scoperto che un'applicazione è molto più semplice se si sposta il traffico nei propri oggetti di dominio (o in alcuni loro composti) dal livello di visualizzazione fino in fondo.

Detto questo, è difficile farlo, perché dovrai rendere la tua HttpSession coincidente con l'unità di lavoro del tuo livello di persistenza. Quindi dovrai assicurarti che tutte le modifiche al database (ad es. Creazione, aggiornamenti ed eliminazioni) siano intenzionali. In altre parole, non si desidera che il livello di visualizzazione abbia un oggetto dominio, un campo viene modificato e la modifica viene mantenuta senza che il codice dell'applicazione salvi intenzionalmente la modifica. Un altro problema importante da affrontare è garantire che la semantica transazionale sia soddisfacente. Di solito, il recupero e la modifica di un oggetto di dominio avverrà in un contesto transazionale e non è difficile rendere il livello ORM necessario per una nuova transazione. Ciò che è difficile è una transazione nidificata, in cui si desidera includere un secondo contesto transazionale nel primo aperto.

Se non ti dispiace indagare su come un'API non Java gestisce questi problemi, vale la pena guardare il Record attivo di Rails, che consente alle pagine del server Ruby di lavorare direttamente con il modello di dominio e attraversare le sue associazioni.