170 messaggi dal 17 febbraio 2009
Ciao, ho ricevuto incarico di sviluppare un intero gestionale per un'azienda produttrice di semilavorati e prodotti finiti.

L'azienda conta agenti sparsi su tutto il territorio nazionale e vuole fornire a tutti i puntivendita un servizio (applicazione web) tramite il quale sia possibile effettuare ordini, consultatore lo stato degli ordini, accesso al catalogo, ecc.. ecc...

Per quanto riguarda la logica interna all'azienda stessa, è necessario sviluppare un'infrastruttura che consenta di ricevere gli ordini dall'applicativo web, distinta base, magazzini, ecc.. ecc.. esclusa parte contabile affidata a software di terze parti.


Parlando in termini "informatici" programmmo in asp.net da 3 anni circa, ho sviluppato un piccolo cms web con il quale fornisco ai clienti siti web dinamici e configurabili. Ho acquistato 2 mesi fa il libro "ASP.NET 4.0 in C# e VB guida completa per lo sviluppatore" che è proprio MADE IN THIS SITE :)

Ho approfondito tramite letture apposite (Enterprise Solution Pattern di Microsoft, e Architecting Microsoft® .NET Solutions for the Enterprise) per approfondire l'architettura software a 3 layers.
Ho anche "giocato" un po con Entity Framework, e sono rimasto davvero sbalordito dalla grande facilità d'uso e dai vantaggi che offre in termini di produttività e semplificazione.


Il mio obiettivo è dunque quello di sviluppare questa grande applicazione (ovviamente suddivisa in sottoapplicazioni e/o moduli) per riuscire nell'impresa sopra citata. Devo dunque decidere l'approccio migliore da usare per iniziare i lavori ed assicurare al software una grande flessibilità ed estendibilità. Successivamente vorrei anche creare un apposito servizio web (sopra lo strato BLL, che mi consenta di collegarmi al sistema tramite apposita applicazione per iPhone/iPad..., ma questi sono solo dettagli al momento :) ).

Io avrei pensato, per quanto concerne il gestionale interno all'azienda (CRM, MRP, Distinta Base, eccc.. ecc...):

- architettura 3 layer.

- DAL: utilizzando Entity Framework. ( Domanda: Ma le classi come ad esempio CustomerEngine che contengono i metodi NewUser(name,blabla, blabla) le devo implementare all'interno di un eventuale Facade del DAL, oppure direttamente sul BLL ?? )
In oltre, mi ocnsigliate di seguire l'approccio Model-First o Database-First ???

- BLL suddivisa in moduli (namespace appositi per Distinta Base, Magazzino, ecc... ec...)

- UI in asp.net o asp.net mvc, non ci tengo molto a capirlo adesso perchè ad ogni modo riguarda solo lo strato Presentation al momento.


Software utilizzati: Visual Studio 2010, Sql Server 2008 Express (al momento).
Anche l'applicativo interno, volevo realizzarlo Web-Based su Intranet aziendale.

Partendo da questo "spunto..." attendo tanti consigli e considerazioni da voi BIG!!! Grazie!
Modificato da vailfox il 19 novembre 2010 11.40 -
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.

Ing. Riccardo Golia
Microsoft MVP ASP.NET/IIS
ASPItalia.com Content Manager
http://blogs.aspitalia.com/rickyvr
http://ricky.aspitalia.com
http://www.riccardogolia.it
415 messaggi dal 13 novembre 2009
Direi che la questione relativa a creare un servizio per sviluppi futuri (Iphone/Windows phone) sia comunque importante sin da subito.
D'altronde ci dice che non si possa usare un servizio per interrogare la base dati, vedi ad esempio RIA Service. Direi che a leggere quanto scrivono qui Casati e Consolini sia ottimo per capire cosa fare:
http://www.aspitalia.com/articoli/asp.net/jquery-ajax.aspx
Modificato da flaviovb il 25 novembre 2010 10.20 -
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.

Ing. Riccardo Golia
Microsoft MVP ASP.NET/IIS
ASPItalia.com Content Manager
http://blogs.aspitalia.com/rickyvr
http://ricky.aspitalia.com
http://www.riccardogolia.it
415 messaggi dal 13 novembre 2009
Condivido,
d'altronde una analisi fatta bene evita tanti problemi/implementazioni dopo.

Flavio
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 -

Ing. Riccardo Golia
Microsoft MVP ASP.NET/IIS
ASPItalia.com Content Manager
http://blogs.aspitalia.com/rickyvr
http://ricky.aspitalia.com
http://www.riccardogolia.it
415 messaggi dal 13 novembre 2009
No,
non mi sono spiegato bene io. Io non suggerivo esplicitamente di usare RIA.
Mi soffermavo solo sulla questione Iphone/Winphone come tema da analizzare subito e non dopo per capire se utilizzare subito una soluzione compliant.

Ciao
Modificato da flaviovb il 25 novembre 2010 11.33 -
170 messaggi dal 17 febbraio 2009
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 -

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.