Faccio una premessa: la mia sarà una risposta molto "DDD biased" :-) Meglio una factory (che io tipicamente implemento come metodo statico esposto dall'entità stessa), perché considero più leggibile ("Code is documentation"):
ProductionDowntime dt = ProductionDowntime.DefineDowntimeForMachine(theMachine, startingDateTime, endingDateTime, reason);
rispetto a:
ProductionDowntime dt = new ProductionDowntime(theMachine, startingDateTime, endingDateTime, reason);
in pratica, uso le factory (previa restrizione della visibilità del costruttore, che lascio sempre private o protected) e la loro firma per rendere più evidente il "senso" della costruzione che sto effettuando
.A
Io uso factory quando le entity sono complesse, e qui quello che dice Andrea è sacrosanto. Se una entità ha più di un costruttore le factory aiutano. In un caso io ho
DownloadedPage page = new DownloadedPage (Uri, int, int)
e
DownloadedPage page = new DownloadedPage (Rui,String)
Il primo vieen usato in caso di errore e vuole l'errore http e un codice di errore interno, il secondo crea una pagina ok. Ora cosi il codice sarebbe molto più leggibile
DownloadedPage page = DownloadedPage,CreateForDownloadError (Uri, int, int)
DownloadedPage page = new DownloadedPage.CreateValid (Uri, int, int)
Il fatto di dovere scrivere più codice risulta banale con resharper, per cui puoi prendere una classe e fare Extract interface ed in qualsiasi momemnto puoi fare pull up e pull down nella gerarchia.
Alk.
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
No, non si parlava di interfacce :-) La tua domanda era: "perche' in diversi esempi vedo usare una EntityFactory ... invece che usare ... un banale, caro vecchio costruttore?" ed io ti ho dato la risposta "DDD style". Tutto qui :-)
"la mettiamo" che evito come la peste le "factory" che EF implementa nelle entità perché sono un insulto alla intelligenza umana e sto provando a verificare la "sostenibilità" di uno scenario "POCO/Code Only" con EF facendo fluent mapping. In entrambi i casi (EDMX "classico" e classi POCO) implemento le mie factory che devono "garantire" che gli aggregate nascano sotto una buona stella :-)
C'è un esempio "primordiale" nel DAL "EF" di NSK, ma è largamente incompleto (leggi: la quota di modello già mappata è ridotta) causa carenza di tempo.
buona serata,
L'Id di "Customer" è la proprietà "Id", e mi sembra che nel file di mapping emerga chiaramente... O forse non ho capito la domanda :-)
Argomento "Aggregate": visto che ho ricevuto anche alcune richieste via mail in merito a questo tema, credo che scriverò un post ad hoc sul blog. In breve (e semplificando), in DDD gli Aggregate sono i grafi di oggetti che il sistema si impegna a gestire: per esempio, un grafo che abbia come root l'entità "Order" molto probabilmente avrà una dignità propria e sarà un aggregate. Sempre per esempio, molto probabilmente in un dominio "real world" un grafo che abbia come root una istanza di OrderItem non sarà un aggregate, e quindi il sistema non ne prevederà una gestione diretta.
Ti consiglio comunque la lettura del libro di Evans, che secondo me è da leggere più di una volta :)
alk.