jankyBlog

ate queste 5 gemme (soprattutto per l'ultima)...Il risultato a più alto impatto nel vostro codice sarà:

Oggetti di dominio che non avranno più responsabilità specifiche di visualizzazione, binding, persistenza, e varie attività funzionali.
Il loro compito sarà maggiormente concentrato nell'esprimere (nel codice) i concetti del modello analitico.

Vediamo come si può mantenere poco inquinata una Entity del Dominio, delegando a chi di dovere...le proprie responsabilità.
(Ho messo tra parentesi dei framework di esempio, ovviamente  che ci possono essere d'aiuto, la cui scelta è puramente tecnlogica, ma dal punto di vista architetturale...l'importante è rispettare la delega)

Responsabilità di Persistenza:
Delegate nel Layer Infrastrutturale di storage (posso usare NHibernate).

Responsabilità di Configurazione, Assemblaggio e Wiring:
Delegate nei Layer infrastrutturali (posso usare Spring.NET)

Responsabilità di Visualizzazione, Ordinamento, Binding:
Delegata nel Layer di UI (posso usare ObjectViews).

Responsabilità di Sicurezza, Transazioni, Logging:
Delegata a configurazioni (posso usare Spring.NET AOP)

Responsabilità di Validazione Contestuale:
Delegata nel Layer di Business/Application (posso usare NRuleValidator).

Vuol dire che le entity non devono contenere logica di business?
No. Tuttaltro. Qualsiasi metodo/funzione che non dipenda dai servizi che ho precedentemente delegato può essere contenuto in oggetti di dominio.

A breve un esempio di layering e anche di come possa essere partizionata la logica di business.

Qualche ringraziamento:
A luka per l'idea delle letteronze :-)
Al pres per le belle discussioni architetturali fatte davanti ad un buon mirto, o del buon vino a seconda dei casi.
A luca del tongo, che in pratica ha dato il LA a questa serie di post semplicemente chiedendomi via mail: "Che ne pensi delle entità anemiche?" :-)

Nei prossimi post vedremo come affrontare il layering vero e proprio.