Oggetti: miscela di dati e infrastruttura?

Naviga le tue risposte
1

Nel nostro codice abbiamo alcune classi che rappresentano la logica aziendale. Prima dell'uso, vengono creati e popolati con due tipi di input:

  • dati aziendali richiesti per l'esecuzione (ad esempio name , maxValue ...)
  • riferimenti infrastrutturali ad es. database, bus messaggi, client http ... ecc., tutto ciò che non è correlato al business, ma necessario per la comunicazione con l'infrastruttura di underlaying.

Abbiamo le seguenti opzioni per separare gli input:

/ A ha tutto nel costruttore: 

public Foo(String name, DbRef db)

Mi piacerebbe essere in grado di separare in qualche modo questi due tipi di input. Poiché il numero di argomenti può essere grande, non voglio sovraccaricare il costruttore o farlo con un numero enorme di argomenti.

/ B infra nel costruttore, dati tramite setter 

public Foo(DbRef db)...
public Foo setName(String name)...

In questo modo non puoi creare un oggetto senza passare l'infra, ma devi aggiungere una validazione extra se alcuni argomenti richiesti non mancano (non c'è un controllo in fase di compilazione per questo).

/ C dati richiesti nel costruttore, infra e dati opzionali tramite setter 

public Foo(String name)...
public Foo bind(DbRef dbref)...
public Foo setMaxValue(int maxValue)...

In questo modo non devi dimenticare di chiamare bind , ma almeno è sempre lo stesso metodo e questa associazione può essere eseguita automaticamente, ad es. proxy, probabilmente, per ridurre possibili errori umani.

Ho iniziato con B ma ora mi sto appoggiando alla C.

Come faresti ad architettare questo?

    
posta igor 18.03.2017 - 13:31
fonte

1 risposta

1

In primo luogo, non vorrei accoppiare i concetti di business alle preoccupazioni dell'infrastruttura - dare un'occhiata a "port e adattatori", l'infrastruttura dovrebbe adattarsi ai porti primario / secondario del dominio. I database, in questo contesto, sono una porta secondaria (qualcosa che viene chiamata dall'oggetto dominio, piuttosto che qualcosa che chiama l'oggetto dominio).

Per quanto riguarda il costruttore / la proprietà / l'iniezione del metodo, considera questo: Il concetto 'x' è un intero reale 'x' senza dipendenza 'y'? Un cliente senza nome e amp; id probabilmente non è valido, quindi non renderlo possibile (preferisco un'iniezione del costruttore). Cambiare i dati tramite setter è generalmente una cattiva idea IMO, perché introduce l'accoppiamento temporale e la necessità per tutti gli oggetti colaborativi di interrogare lo stato, introducendo molti altri problemi. L'iniezione del metodo è il modo migliore per introdurre dipendenze incostanti, qualcosa che può essere usato e trascinato via più tardi, cioè non qualcosa che definisce l'oggetto, ma qualcosa di cui ha bisogno per fare qualcosa di specifico. Potrebbe trattarsi della registrazione di un osservatore, persistente in un repository o notifica tramite messaggistica.

In generale, penso che odori soprattutto come la 'logica del business' sia inquinata dai problemi dell'infrastruttura, e fino a che non la disaccordi, né A, B o C avranno un vantaggio significativo. Spero che questo aiuti

    
risposta data 18.03.2017 - 13:56
fonte

Leggi altre domande sui tag

Domanda di modellazione del database Creazione di un singleton per accedere ai dati statici