Stiamo provando a creare un'applicazione ASP.NET MVC 4 utilizzando il framework di entità con un approccio basato sul modello di stile di sviluppo basato sul dominio. Come puoi vedere nella nostra parte del livello dominio, abbiamo un design complesso. Dobbiamo caricare l'entità con metodi pigri e desiderosi. Sfortunatamente abbiamo un grosso problema con questi metodi nel framework di entità.
Come comprendiamo, per il carico entusiasmante in EF dobbiamo usare il metodo Include
e dare una stringa di proprietà e proprietà delle proprietà ecc. (In Hibernate e java potremmo usare annotation top of member per caricare con entusiasmo ed è stato molto più facile di questo approccio). Ma il problema orribile è che abbiamo strutture ereditarie e un pesante polimorfismo, in questi stati non abbiamo quella stringa che dovremmo includere perché non sappiamo quale classe di classe derivata sia selezionata per capire quali proprietà dovrebbero includere.
Ad esempio, come puoi vedere un risultato ha una collezione di elementi e poi decide di aggiungere un gruppo a questa raccolta e ognuno di questi gruppi ha alcuni gruppi e campi (come il modello di composizione). Ora immagina di voler caricare un risultato come quello parlato sopra. Quando voglio scrivere una stringa di data include non so quali elementi di questo risultato sono gruppi. Perché non possiamo prevedere che questi elementi siano gruppi e quindi questi gruppi hanno una raccolta di elementi che dovrebbero essere caricati.
this.Items = new List<Item>
{
new Group(
a,
new List<Item>
{
new Field(b),
new Field(c),
new Field(d),
Finalmente abbiamo una domanda critica: la struttura delle entità è progettata per le applicazioni aziendali con un dominio complesso e un approccio DDD? In caso negativo, come seguiamo l'approccio di Martin Fowler e Eric Evans nell'ingegneria del software e nell'applicazione aziendale in C #?