1) Fossi in te, userei assolutamente un approccio domain driven. Un'applicazione enterprise come quella che descrivi, implica una complessità che giustifica un approccio di questo tipo ed include necessariamente una serie di scenari e casi d'uso tali per cui il modo con cui i dati vengono persistiti rappresenta "solo" un dettaglio, nell'economia dell'intero progetto. Il focus non è sul database, ma sui casi d'uso, chiaro?

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.

3) SQL Server 2008 Express è limitato ad una CPU e 1 GB di RAM. Valuta se la cosa sia sufficiente per i tuoi scopi.

4) WebForms o MVC? Dipende se vuoi fare unit testing sullo strato di presentazione o meno. Peraltro, essendo un'applicazione intranet, l'uso di controlli e librerie di controlli smart ti potrebbe semplificare non poco le cose, anche se vai ad usare in modo importante il ViewState. Valuta se per te ha maggior valore la produttività e la disponibilità di controlli server pronti all'uso rispetto alla testabilità e al controllo del markup. Probabilmente la prima opzione può andare bene in un'applicazione come la tua.

Se hai altri dubbi, spara. Noi siamo qua!

Ciao, Ricky.

Certo, si possono usare servizi se richiesto, ma in un'applicazione enterprise in genere non è una buona idea avere un servizio di tipo CRUD sui dati.

I servizi devono essere strutturati per avere un contratto coarse-grained, con operazioni di alto livello orientate ai casi d'uso. Contrariamente, un DAL deve fornire un accesso granulare ai dati, il che lo rende poco adatto ad essere esposto direttamente, se non tramite uno strato intermedio che aggrega i comportamenti secondo le logiche di business (BLL).

Inoltre, prevedere un servizio per accedere ad una funzionalità significa fare una chiamata out-of-process. Trasformare uno stack-frame in messaggio e viceversa implica comunque un costo che va preso in considerazione.

Inoltre, isolare il DAL dietro uno strato di servizi implica conseguenze anche nell'uso dell'ObjectContext di EF.

Come sempre, vanno valutati i pro e i contro.

Ciao, Ricky.

D'accordo, un'analisi ben fatta aiuta a evitare problemi dopo.

Questo non toglie che, IMHO, utilizzare un approccio basato su RIA Services in uno scenario come quello descritto da vailfox non va bene, a meno che non si voglia implementare un gestionale basato su Silverlight. Il che, mi pare, non sia nelle intenzioni di vailfox.

Ciao, Ricky.

---

Modificato da rickyvr il 25 novembre 2010 12.23 -

Ciao, non potete immaginare quanto mi senta risollevato a vedere la vostra disponibilità qui sul forum! :) :)
Ho 22 anni e sono al terzo anno di informatica applicata, discutere e scambiare opinioni con Voi (e con ciò che avete scritto nelle vostre firme) mi rende davvero "piccolo piccolo"!! Ad ogni modo, grazie di tutto!


Dunque, in questi giorni ho letto qualcosa su questo testo:
http://www.amazon.com/NET-Domain-Driven-Design-Solution-Programmer/dp/0470147563
il quale mi sembra un buon compromesso tra "pratica e teoria".

Ad ogni modo, i vostri consigli "sul campo" vanno ben oltre le aspettative che potrei trovare sui testi.

Riccardo, sto studiando l'architettura usata per la vostra applicazione Model Virtual Casting, e ho visto (tramite i video presenti nelle varie sezioni del sito) le vostre sessioni tenute a Firenze.

Al momento, una cosa che non mi è proprio chiara è l'utilizzo di entity framework all'interno del DAL. Ovvero, nello strato DAL aggiungo il file edmx e genero le entità partendo da alcune tabelle presenti nel mio DB di prova. In oltre, ho aggiunto il template per le classi POCO. Fatto ciò, inserisco un nuovo progetto nella mia demo che chiamo per l'appunto BLL. qui aggiungo il riferimento al DAL e creo delle classi (ad esempio: UserEngine) nella quale aggiungo metodi come ad es: GetUsers o DeleteUsers(byval id as Integer).
Successivamente aggiungo un nuovo progetto che chiamo a sua volta UI e aggiungo il riferimento al BLL.

Fatto ciò, ad un datagrid (esempio GridUsers) assegno come sorgente dati UserEngine.GetUsers (che restituisce una lista di Users).

Il problema è che il compilatore non riconosce il tipo User tornato dal metodo GetUsers. Questo perchè non ho ancora creato un object model condiviso da tutti e 3 gli strati all'interno della soluzione.

Adesso... devo scrivere io stesso le varie classi che rappresentano le entità della mia applicazione?? metterle in un "progetto" condiviso da tutti e 3 gli strato e chiamarlo ad esempio "Core" ??

Oppure devo usare lo stesso object model che mi genera entity frameworl tramite il template delle classi POCO e renderlo "visibile" a tutti e 3 gli strati??

Sono consapevole di aver posto delle domande "troppo basilari" visto l'entità e la mole del progetto da affrontare, ma guardando i vari esempi, non ho ancora capito la relazione tra l'object model generato da entity framwork e quello presente nel progetto "Core" condiviso da tutti gli strati dell'applicazione!


Per creare lo strato UI preferisco utilizzare le WebForms (con la quale ho più dimestichezza) e al momento preferisco tralasciare eventuali test dull'UI per l'appunto. (la priorità al momento va al cuore vero e proprio del sistema :) ).


A livello teorico ho capito la defferenza tra un approccio DataBase driven e Domain Driven, però una vera implementazione partendo da zero ha ancora per me molti lati oscuri..., come ad esempio la parte riguardante le interfacce presenti nella cartella "Commons" di MVC. Ho capito che riccardo le utilizzava per consentire uno sviluppo parallelo da parte del Team di sviluppo, e per ragionare appunto in "Termini Dichiarativi".


Mi consigliate qualche buon testo o del materiale utile per iniziare a scrivere una demo o una prima versione beta del cuore del mio sistema?? Non voglio focalizzarmi troppo sulla teoria, ma voglio capire e fare le cose in modo parallelo! :)


Grazie ancora a voi tutti per i consigli! :)

---

Modificato da vailfox il 25 novembre 2010 18.28 -

---

Modificato da vailfox il 25 novembre 2010 18.30 -