Struttura software e soluzioni - DotNetWork - Forums - Forums Tecnici - .NET Framework

Senza risposta Attivi

Forums Cerca

Forums > Forums Tecnici > .NET Framework - Desktop development

Struttura software e soluzioni

Ultimo Post 21 lug 2010 07.52 by Hidden. 7 Risposte.

Ordina:

	Prev Prossimo
Non sei autorizzato ad inviare una risposta.

Autore

Messaggi

Posts:663

12 lug 2010 11.02
Salve dopo un pò di tempo che programmo mi sono accorto di un particolare a cui prima non facevo caso. Il tutto è emerso dalla lettura di un articolo di Sabrina. Nello sviluppo di una applicazione io creao all'interno dalla mia applicazioni delle varie classi accessorie (se questo è il termine corretto) come per esempio mi creo un classe che si occupa di tutte le operazioni inerenti al database, carico dati da una query, query di modifiche, ecc. Da alcuni articoli di Sabrina ho notato che tutte queste operazioni alcuni, come Sabrina, le affidano ad un'altra applicazione che viene inserita nella soluzione, solitamente chiamate App.UI, App.Data ecc . Ora quello che vorrei comprendere è perchè creare un'altr'applicazione da inserire nella soluzione anzicchè una semplice classe nell'applicazione stessa? Sono certo che se costoro che utilizzano questo metodo (che sono molto più qualificati e preparati di me) lo fanno un vantaggio o motivo sicuramente ci sarà. La mia domanda quindi è : Qual è questo vantaggio o motivo? Grazie

Posts:537

12 lug 2010 12.14
Anche io mi facevo le tue stesse domande. in teoria avere la struttura App.UI App.Data....ed io aggiungo App.BS o App.BL hai un sistema più ordinato. più di questo, quello che consiglio è avere anche un proprio framework per quelle procedure che usi in tutti i tuoi applicativi. Io per esempio ho Panatronic.Base.Data che non è altro un insieme di classi che si occupano di connettersi e operare sui database. Per ora la mia dll lavora su Db Access e SQL.. in questo modo da una mia qualsiasi applicazione posso richiamare la funzione Panatronic.Base.Data.ConnectSQLHelper.BuildStrCn...e passandogli il nome server con nome DB, mi genero la stringa di connessione al DB..senza preoccuparmi di ricordarmela ogni volta....ed essere sicuro di non sbagliare.. per altri chiarimenti ...scirvi...che Sabrina..ed Alberto sono più esperti.

Posts:663

12 lug 2010 13.00
Ti ringrazio diciamo che in parte a questi motivi ci avevo pensato anche io. Il mio dubbio era se ci fosse qualcosa di più sostanzioso. Comunque grazie

Posts:5

13 lug 2010 13.10
Inserito da Hidden su 12 lug 2010 12.02 ... Ora quello che vorrei comprendere è perchè creare un'altr'applicazione da inserire nella soluzione anzicchè una semplice classe nell'applicazione stessa? La mia domanda quindi è : Qual è questo vantaggio o motivo? Grazie Ciao, Implementare i vari layers in librerie separate ti permette in primo luogo di poterli distribuire all'occorrenza su più server; inoltre sei sicuro di non introdurre -anche involontariamente- dipendenze improprie tra i layers (...una classe di accesso ai dati che fa riferimento direttamente ad una textbox di un webform non è il massimo); infine mi sembra meglio avere una dll compilata che fa univocamente capo a dei sorgenti ben definiti che tante classi uguali sparse tra le varie cartelle app_code dei progetti

------------------------- Ciao sspintux

Posts:811

15 lug 2010 12.49
Concordo con quanto detto da sspintux, ad ogni modo, la costruzione di una applicazione utilizzando progetti separati e soluzioni separate oltre a servire per evitare cose turpi quali un metodo di una delle classi dati che fa qualcosa in modo diretto su una classe form, serve per organizzare logicamente e mentalmente chi programma, per recuperare le cose velocemente e aiutarci nella manutenzione. Perché usare Dll separate invece che creare delle cartelle in una singola applicazione? Se l'applicazione è piccola e utilizza tutto quanto subito, non c'è alcun vantaggio specifico. Se l'applicazione è estesa, articolata e modulare, è inutile caricare la DLL di gestione degli articoli di magazzino se l'utente apre lo scadenzario, piuttosto che è inutile caricare la DLL di gestione del caricamento di documenti da fonti esterne quando l'utente sta cercando un numero telefonico. Pertanto, fatto salvo le DLL strutturali, che sono quelle che io ho costruito nei miei vari articoli che sono riutilizzabili in tutte le nostre applicazioni e vanno gestite in modo autonomo, per evitare di usare il copia e incolla e doversi ricordare di correggere un baco in 100 posti diversi. Le applicazioni vere e proprie, possono essere strutturate su una o più DLL ed un Exe in base al funzionamento e all'utilizzo. La modularità è un vantaggio in alcuni casi molto importante quando ad esempio abbiamo un modulo generico di gestione dei contatti, che può essere utilizzato per gestire le anagrafiche sia in un programma di gestione magazzino, sia in un programma di CRM, sia in un programma per la profilazione di candidati ad un ruolo aziendale e così via. spero di averti dato delle idee saluti

Sabrina

Posts:663

19 lug 2010 12.56
Perché usare Dll separate invece che creare delle cartelle in una singola applicazione? Se l'applicazione è piccola e utilizza tutto quanto subito, non c'è alcun vantaggio specifico. Se l'applicazione è estesa, articolata e modulare, è inutile caricare la DLL di gestione degli articoli di magazzino se l'utente apre lo scadenzario, piuttosto che è inutile caricare la DLL di gestione del caricamento di documenti da fonti esterne quando l'utente sta cercando un numero telefonico. In particolar modo quello che non ho capito è il senso di questa frase Se l'applicazione è estesa, articolata e modulare, è inutile caricare la DLL Scusami ma questa non mi è proprio chiara. Da quello che avevo capito era che nel caso io sto facendo una piccola applicazione dove utilizzo tutto e subito è chiaro che utilizzare un progetto a parte per farmi passare i dati dal database potrebbe risultare senza vantaggio. Ma nel caso di un'applicazione più complessa caricare un progetto (dll) che si occupi del relazionamento con il database passandomi i dati richiesti in questo caso allora penso che la cosa potrà risultare vantaggiosa. Ho capito bene?

Posts:811

20 lug 2010 20.22
la risposta è NI, la convenienza all'uso delle DLL non è quella relativa all'avere una DLL che ti passa i dati. anche se ovviamente separare la gestione dati dalla user interface è opportuno per questioni di organizzazione, manutenibilità e così via. La convenienza nell'uso delle DLL separate è dovuta al fatto che una DLL viene caricata solo quando un oggetto in essa contenuto viene istanziato o un metodo statico viene richiamato. Pertanto, se tu hai una applicazione che può essere suddivisa in una parte comune, sempre indispensabile (ad esempio le anagrafiche clienti e fornitori) ma altre parti non sono sempre necessarie, ad esempio I documenti di magazzino, piuttosto che la prima nota, che non sono usati contemporaneamente di solito, possono divenire dei moduli specifici, quindi progetti e dll diversi per ogni modulo, dati dei documenti, user interface dei documenti di magazzino, dati della prima nota user interface della prima nota. In questo modo eviti di caricare 30 mega di codice quando te ne servono solo10. saluti Sabrina

Sabrina

Posts:663

21 lug 2010 07.52
Ok Perfetto ora il concetto è più chiaro. Quindi solitamente è conveniente strutturare la applicazioni in più soluzioni sia per quanto riguarda l'intefaccia che per quanto riguarda la gestione dei dati. Ok ti ringrazio questo mi sarà molto utile a snellire e alleggerire le mie applicazioni. In fatti fino ad oggi utilizzavo un sacco di classi ma solitamente tutte nello stesso progetto. Per gestire i dati creavo un unico progetto con le query che mi servivano per interfacciarmi al database cosa che spesso mi rallenta. Grazie.

Non sei autorizzato ad inviare una risposta.

Forums > Forums Tecnici > .NET Framework - Desktop development

Active Forums 4.1