rickyvr ha scritto:
1)
....
2) L'uso di Facade permette di limitare le dipendenze tra strati ed è sempre consigliabile. Per il DAL userei il pattern Repository applicato con EF su un object model POCO.
....
Dunque, ho trascorso il finesettimana a leggere i primi capitoli di ".NET Domain-Driven Design with C#". Ho approfondito l'"Infrastructure Layer" che secondo il testo dovrebbe coincidere con il DAL. Sul testo di fa riferimento al Repository Pattern (Repository Factory) e all'utilizzo dell'approccio "Unit Of Work". Arrivato all'implementazione del BaseRepository che si interfaccia con SqlCE mi sono accorto che... "ovviamente"... non si fa riferimento ad entity framwork e quindi viene scritta tutta la parte di interazione con il DB. Oltre a questo, il modello "Unit of Work" mi sembra colmare le lacune che c'erano nel 2008 (anno di pubblicazione del testo) quando ancora EF non esisteva.
Detto ciò, devo focalizzarmi su quanto affermato da Riccardo, e cercare di implementare un Pattern Repository applicato con EF.
Attualmente devo creare l'"anagrafica prodotti" e la "distinta base di produzione" del gestionale in questione.
I 2 "moduli citati" devono prevedere le classiche operazioni di cancellazione, aggiornamento, selezione e ricerca dei prodotti. Sono operazioni che in un'ottica Database Driven sono una sciocchezza, ma seguendo il modello Domain Driver con "persistence ignorance" le cose si complicano un po e assumono caratteristiche diverse.
Ho notato con nell'applicazione MVC lo strato DAL e costituito interamente dal progetto "ASPItalia.ModelVirtualCasting.EntityFramework" sotto la cartella Repository. Ho capito che per risolvere il mio problema devo comprendere appieno la stuttura di questo progetto e una cosa che ho subito notato è la presenza del file "Model.Context.tt" che rapprensente il "contesto" di EF. Questo è slegato dal modello "e dal file .edmx" che invece giace nel progetto "ASPItalia.ModelVirtualCasting" ovvero il BLL dell'applicazione. Un prima domanda è... come avete fatto a slegare le 2 cose?? quando aggiungo un Entity Data Model al mio progetto in automatico mi vengono create le entità POCO (con l'utilizzo dell'apposito Template) + il file context associato. Come posso spostare il contesto in un altro progetto e mantere il modello generato con EF ancora valido?? E se faccio delle modifiche al modello (tramite l'editor di EF) il file context mi viene rigenerato nel progetto corrente e viene aggiornato quello già esistente.
(Ovviamente il context non l'avete scritto voi a mano, ma viene generato automaticamente dal file edmx giusto?)
Non vorrei aver detto sciocchezze, ma il dubbio ancora rimane!
La cartella "Wrapper" che ruolo gioca nell'applicazione?? è il punto di collegamento con i layer soprastanti?? A che server il Context Wrapper??
Ho notato che il progetto "ASPItalia.ModelVirtualCasting.EntityFramework" contiene le implementazioni delle interfacce presenti nella cartella "Common" di "Model Virtual Casting" (dovrebbe rappresentare il BLL).
Questo riferimento ad un "layer" soprastante non collide con l'architettura n-layered, dove l'n-esimo l'layer può fare riferimento ai soli layer sottostanti??
Capisco però che la soluzione permette di ragionare in termini dichiarativi, consentendo di lavora in modo parallelo conoscendo a priori i metodi e le classi che saranno implementate nei layer sottostanti.
Secondo la struttura adottata in MVC, si potrebbe affermare che il BLL è stato "fuso" con l'UI layer Web e Client ???
In fondo "ASPItalia.ModelVirtualCasting" contiene solo le interfacce e il modello.
Anche qui l'UI Layer "ASPItalia.ModelVirtualCasting.Web" contiene il riferimento a EF (DAL). Questo non va contro la classica architettura 3 layer. l'UI non dovrebbe fare riferimento soltanto al BLL ??
Scusate la mole di domande e dubbi, ringrazio molto tutti coloro che avranno la gentilezza e la pazienza di rispondermi :) !
Ciao!!
Modificato da vailfox il 28 novembre 2010 19.57 -
Modificato da vailfox il 28 novembre 2010 20.03 -
