Variabili tra WinForms

giovedì 14 aprile 2011 - 08.26
Tag Elenco Tags  C#  |  .NET 4.0  |  Windows Server 2003  |  Visual Studio 2010  |  SQL Server 2005

utente Profilo | Junior Member

Secondo voi qual è il metodo migliore per passare variabili tra le form della nostra applicazione?
Nel mio caso, faccio fare il login all'utente e voglio fare sapere a tutte le form chi è e che permessi ha.

AntCiar Profilo | Expert

Ciao.
Secondo me conviene usare delle variabili statiche a basso livello in modo che tutti ci possono accedere.
Cristian Barca

utente Profilo | Junior Member

>Ciao.
>Secondo me conviene usare delle variabili statiche a basso livello
>in modo che tutti ci possono accedere.
>Cristian Barca

Grazie Cristian della risposta.
Anche io avevo pensato ad una cosa tipo un oggetto statico, ma non mi piace tanto l'idea (mi sa di lavoro sporco).

kataklisma Profilo | Senior Member

>Grazie Cristian della risposta.
>Anche io avevo pensato ad una cosa tipo un oggetto statico, ma
>non mi piace tanto l'idea (mi sa di lavoro sporco).

Scusate l'intromissione

Di sporco non c'è nulla....anzi, passare informazioni di questo tipo via form è molto "sporco"!

Puoi dirci come hai strutturato l'applicazione?In particolar modo ci servirebbe conoscere la disposizione in Layer del tutto e dove risiedono le persistenze degli utenti e dei permessi, detto questo andiamo a vedere dove e come inserire le entità legate all'utente loggato ;)
------------------------------------------
Ignazio Catanzaro

http://blogs.dotnethell.it/swdev/

utente Profilo | Junior Member

Beh, indendo di sporco per la mia visione (che è una visione di uno alle prime armi).
Stavo facendo le mie prime prove e ho creato un progetto "Applicazione Windows Form" e ho creato solo un form di login.
Da qui stavo pensando come potevo gestire al meglio lo scambio dei dati all'interno della mia applicazione, tra le varie form.

Successivamente ho letto qualcosa su quello che mi consigliavi nell'altro post e ho intenzione di passare ad un progetto WPF per implementare il pattern Model-View-ViewModel.
Se vi può interessare ho trovato una video guida interessante a questo indirizzo: http://blogs.academicclub.org/romatre/tag/model-view-viewmodel/

Per il resto non c'è ancora una struttura del progetto.
Pensavo di creare le varie View e i vari ViewModel per la gestione delle singole parti però in effetti esiste (nella mia testa) ancora il problema di gestire tutte le varie parti.

kataklisma Profilo | Senior Member

>Beh, indendo di sporco per la mia visione (che è una visione
>di uno alle prime armi).

Tutti siamo stati "alle prime armi" quindi non c'è nulla di cui preoccuparsi :)

>Stavo facendo le mie prime prove e ho creato un progetto "Applicazione
>Windows Form" e ho creato solo un form di login.
>Da qui stavo pensando come potevo gestire al meglio lo scambio
>dei dati all'interno della mia applicazione, tra le varie form.

Grazie alla programmazione ad oggetti hai a disposizione centinaia di pattern e modi per fare qualsiasi cosa tu voglia.

E' necessario però conoscere le effettive potenzialità della OOP ed è un lavoro lungo, molto lungo.

>Successivamente ho letto qualcosa su quello che mi consigliavi
>nell'altro post e ho intenzione di passare ad un progetto WPF
>per implementare il pattern Model-View-ViewModel.
>Se vi può interessare ho trovato una video guida interessante
>a questo indirizzo: http://blogs.academicclub.org/romatre/tag/model-view-viewmodel/

Perfetto, WPF & Pattern MVVM sono strumenti utilissimi per gestire al meglio il Presentation Layer (ovvero quello che l'utente vede e con cui interagisce)

>Per il resto non c'è ancora una struttura del progetto.
>Pensavo di creare le varie View e i vari ViewModel per la gestione
>delle singole parti però in effetti esiste (nella mia testa)
>ancora il problema di gestire tutte le varie parti.

Come ti dicevo, Con WPF e MVVM hai coperto uno degli N Layer del progetto : tutta la logica, che possa essere logica di dominio o quant'altro deve essere sviluppata in layer di piu basso livello che saranno in grado attraverso i Business Object di dare i risultati output previsti. La questione è lunghetta quindi ti consiglierei (se sei effettivamente interessato alla cosa) di studiare un po di ingegneria del software OOP, in particolar modo l'architettura 3 tier (Presentation, Business e Data Layer).

In un progetto che fa uso di base dati, interfaccia grafica ed ha per ovvi motivi un dominio ben preciso, l'architettura a 3 livelli (o Layer) è necessaria quanto imprescindibile.

Grazie alla piattaforma .Net abbiamo diversi strumenti e tecnologie che assegnati ai diversi layer possono dare risultati veramente buoni (basti pensare ad Entity Framework, WPF e WCF).

Buona fortuna ! Se hai bisogno....siamo qui
------------------------------------------
Ignazio Catanzaro

http://blogs.dotnethell.it/swdev/

utente Profilo | Junior Member

>Come ti dicevo, Con WPF e MVVM hai coperto uno degli N Layer
>del progetto : tutta la logica, che possa essere logica di dominio
>o quant'altro deve essere sviluppata in layer di piu basso livello
>che saranno in grado attraverso i Business Object di dare i risultati
>output previsti. La questione è lunghetta quindi ti consiglierei
>(se sei effettivamente interessato alla cosa) di studiare un
>po di ingegneria del software OOP, in particolar modo l'architettura
>3 tier (Presentation, Business e Data Layer).
>

Sicuramente sono interessato ad imparare.
Ma mi chiedevo, il pattern M-V-VM non copre già i vari livelli?
Il model si occupa dei dati (Data Layer)
La view si occupa della presentazione (utilizzando poi nel mio caso WPF, quindi ho 2 livelli di presentazione)
Il viewModel che si occupa della logica

Dove sbaglio?
Che libri mi consigli da leggere?

kataklisma Profilo | Senior Member

>Sicuramente sono interessato ad imparare.
>Ma mi chiedevo, il pattern M-V-VM non copre già i vari livelli?
>Il model si occupa dei dati (Data Layer)
>La view si occupa della presentazione (utilizzando poi nel mio
>caso WPF, quindi ho 2 livelli di presentazione)
>Il viewModel che si occupa della logica

>Dove sbaglio?

In realtà non sbagli, ma ti sfugge una piccola cosa

Il pattern MVVM influisci solo e soltanto per la logica d'interfaccia :

1) Le View sono le viste che "presentano" i dati (Button,Form, UserControl etc...)
2) Il Model è la rappresentazione degli oggetti di dominio cui "stato" verrà elaborato dalle View
3) Il ViewModel è la parte di codice che si occupa del databinding tra gli oggetti della view e i Business Object

Quindi in maniera molto generica possiamo riassumere che nel Presentation Layer vi è la presenza del pattern MVVM e che il Presentation Layer è referenziato al Business Layer per "consumare" gli oggetti di dominio.

Presentation Layer (MVVM Pattern)
|
Business Layer (Oggetti di dominio)
|
Data Layer (Accesso al datasource )
|
Database/Service (DataSource, puo essere un database ma anche ad esempio un WebService o un banale File!)


Considerando un Dominio di tipo "gestionale di magazzino" e nello specifico prendendo come oggetto di dominio "l'articolo" abbiamo bisogno del presentation layer che mostra a video i dati relativi all'articolo, del Business Layer che incorpora la rappresentazione in oggetti dell'Articolo e del Data Layer che si occupa di prelevare e persistere i dati riferiti all'articolo preso in considerazione.

>Che libri mi consigli da leggere?

Ti consiglierei di leggere :

1) Principi di Ingegneria del software (Pressman)
2) Microsoft .NET: Architecting Applications for the Enterprise (Dino Esposito, il libro è scritto in Inglese)
3) Se non l'hai ancora fatto acquista un buon libro sul C# della catena di Microsoft.


P.S Cosa molto importante è capire quando è necessario l'utilizzo di tali architetture e tali pattern : se il sorgente è di piccole dimensioni e il progetto non è vasto è completamente inutile strutturare tutto cio in quanto per assurdo si andrebbe solamente a complicare il lavoro, ovvio che a fini didattici tutto va bene

------------------------------------------
Ignazio Catanzaro

http://blogs.dotnethell.it/swdev/

utente Profilo | Junior Member

>P.S Cosa molto importante è capire quando è necessario l'utilizzo
>di tali architetture e tali pattern : se il sorgente è di piccole
>dimensioni e il progetto non è vasto è completamente inutile
>strutturare tutto cio in quanto per assurdo si andrebbe solamente
>a complicare il lavoro, ovvio che a fini didattici tutto va bene

Lo scopo finale (dopo le mie iniziali prove) è quello di creare un software che faccia varie cose.
Per non rendere troppo complesso il progetto vorrei creare un core e poi implementare funzionalità come plugin/moduli.
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2017
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5