Quando ho utilizzato IoC Container nel mio ultimo progetto, sono finito con entità anemiche e gran parte della mia logica di business in Stateless Services.
Ho visto progetti scritti da altri sviluppatori che utilizzano "Inversion of Control" e sono sempre "Anemici".
Poiché "Anemic Domain Model" è anti-pattern, è possibile utilizzare IoC e Rich Domain? Sono dei buoni esempi, progetti open source che lo fanno?
Per i principianti: i sinonimi DI e IoC non sono . Mi dispiace ma devo indicarlo (mi sembra che tu pensi che lo siano).
Per quanto riguarda la tua richiesta ... Beh, la dipendenza dall'iniezione è solo uno strumento. Il modo in cui utilizzerai questo strumento è completamente separato. Ci sono anche altri strumenti (modelli di progettazione) che potrebbero aggiungere il problema. Ad esempio, ritengo che l'ampia adozione del pattern MVC sia uno degli ingredienti chiave per la formazione di anti-pattern del modello di dominio anemico: i controller (in applicazioni più semplici, in quelli più complessi che sarebbero ulteriori livelli di servizio) si assumono la responsabilità di convalidare le regole aziendali , rafforzandoli e trasformando le entità DB in qualcosa di utile, mentre Business Layer si trasforma in un semplice livello di accesso ai dati che è semplice ORM con mappatura uno-a-uno alle entità del database.
Certamente è come progetta la tua applicazione - puoi creare un modello di dominio corretto se lo desideri, e tutti questi IoC, DI, MVC non ti fermano. Cosa potrebbe fermarti è la tua squadra. In qualche modo devi convincerli a utilizzare la strada giusta e potrebbe essere difficile, visto che molti sviluppatori di software non hanno un solido background architettonico.
La maggior parte (se non tutte) le applicazioni sono un mix di infrastrutture e problemi di dominio. Quando raggiungi un certo livello di complessità, semplifichi la gestione se il dominio è separato dall'infrastruttura in modo che sia più facile ragionare e possa evolversi indipendentemente.
Ovviamente il modello di dominio deve ancora comunicare con il resto del sistema e solitamente questo sarà con i servizi stateless (che fanno parte del dominio) che hanno problemi di infrastruttura (come l'accesso al database) iniettati in essi. L'uso di un contenitore IoC non rimuove questa dipendenza, ma sposta la sua configurazione in un'area separata, rendendo ancora più facile ragionare e mantenere.
Le entità stanno memorizzando lo stato e dovrebbero essere responsabili delle regole aziendali. Se i tuoi servizi applicano tutti gli invarianti e le altre regole aziendali, è probabile che la logica sia nel posto sbagliato.
Ora, se hai la logica nei posti giusti e tuttavia hai ancora finito con servizi che non sono altro che involucri intorno a infrastrutture e entità che sono solo sacchetti di proprietà, allora è molto probabile che il dominio non sia complesso abbastanza da giustificare il sovraccarico del proprio modello. Quasi tutto ciò che leggerete su DDD conterrà una dichiarazione di non responsabilità che è destinata solo a domini complessi, ma questo sembra essere troppo spesso dimenticato.
Vai alla fonte. Inizia con il pezzo di Fowler su Modelli di dominio anemico . Fa riferimento al Domain Driven Design di Eric Evan come esempio di buona pratica. Il codice sorgente è qui . Scaricalo.
Osserva che utilizza Inversion of Control (cerca @Autowired) e ha classi di servizio (BookingService) e classi di "processi aziendali" (ad esempio ItineraryUpdater).
L'articolo originale di Fowler inizia la traccia dell'esempio che stai cercando.
is it possible to use IoC and Rich Domain? Are their any good examples, open source projects that do that?
Immagino tu intenda DI invece di IoC, e il progetto su cui hai lavorato utilizza un contenitore DI come Spring. IoC ha due sapori principali: DI e Pattern Locator. Non vedo perché il pattern Locator dovrebbe essere un problema, quindi concentriamoci su DI.
Non penso che sia possibile, o almeno sarebbe molto difficile. L'aspetto principale dei contenitori DI è che controllano la creazione di oggetti quando li iniettano in altri ("oggetti gestiti"). L'insieme di oggetti gestiti che è vivo durante l'esecuzione dei progetti è indipendente da quali elementi di dominio esistono nel progetto, ma dipende da come gli oggetti sono cablati e da quali ambiti (singleton, prototipo) sono assegnati.
Questo è il motivo per cui non vuoi lasciare che il contenitore DI gestisca i tuoi oggetti di dominio. Ma se crei oggetti manualmente (con nuovo), non puoi ottenere altri oggetti iniettati ai tuoi oggetti di dominio. (Lasciando da parte le possibili soluzioni alternative con il cablaggio manuale.) Poiché sono necessarie queste iniezioni per sostituire le implementazioni con altre, non è possibile sostituire la funzionalità degli oggetti con dominio avanzato utilizzando DI. Quindi, non vorrai inserire funzionalità negli oggetti del dominio, altrimenti perderai le funzionalità del DI.
Non vedo come potrebbe funzionare un ipotetico contenitore DI che non gestisce i tuoi oggetti e nessuna delle implementazioni esistenti lo consente. Quindi è giusto sostenere che DI si basa sulla gestione degli oggetti. Pertanto ti tenterà sempre di suddividere potenziali oggetti Rich Domain in una classe anemica e una o più classi di script di transazione.
Leggi altre domande sui tag dependency-injection