Newsgroup: it.comp.dotnet
Titolo: Logica progetto, consiglio

Piccola applicazione che utilizza SQLExpress come db, 3 pc colegati
nessuna prospettiva a lungo termine di aumento dei pc.
 
LINQ to SQL
Una classe(static) che ha la logica che dialoga con il DataContext. Meglio 
una classe singleton?
Le tre Windows(il progetto č WPF)
 
Grazie per i consigli.
 
Elisabetta 
 
 

 una classe singleton?
 
Singleton e' piu' sofisticato di una classe statica, ma quale scegliere 
dipende dalle tue effettive esigenze: l'unica indicazione di massima e' che 
semplice e' meglio...
 
-LV
 
 

 una classe singleton?
 
nessuna delle due, il ciclo di vita del DataContext deve coincidere con 
la "transazione" di business.
 
.m
 
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
 
blog @ 
http://milestone.topics.it
 
whynot [ at ] topics [ dot ] it
 
 


Quindi metto la logica direttamente nei moduli .cs
delle windows?
 
E se modifico l'interfaccia?
 
Persavo di mettere nella classe, ad esempio, un metodo
che recupera con LINQ i dati dal DataContext:
 
        //...........
        private static NorthWindDataContext nw;
       //...............
        public static List<Customer> filtraCustomersCompanyName(string s)
        {
            using(nw = new NorthWindDataContext())
            {
                var customers = from c in nw.Customers
                                where c.CompanyName.Contains(s)
                                orderby c.CustomerID
                                select c;
                return customers.ToList();
            }
        }
        //..........
 
restituisce quindi una List<T> da richiamare poi dalla windows:
 
this.dataGrid1.ItemsSource = 
miaclasse.filtraCustomersCompanyName("Restaurant");
 
Grazie.
 
Elisabetta. 
 
 

 Elisabetta.


 disconnesse che devono essere nuovamente "attached" al datacontext.
 
...e questo "brucia" la domanda che stavo per fare. :-)
In compenso ce ne attaco un'altra (molto simile): se una property di uno 
degli oggetti caricati non è stata ancora fetchata (perché si è scelto 
di implementarla con lazy loading) e qualche altro attore cerca di 
accederne al valore dopo che è stata disconnessa, scoppia tutto, giusto?
 
Ciao,
Giulio
 
-- 
 
 


 
Ok.
 
Mettiamo il caso che io abbia nella Windows una dataGrid e alcune
TextBox. Come detto prima, ad esempio all'avvio carico la
dataGrid con una routine della mia classe.
Inserisco dati nelle TextBox, chiamo la routine di inserimento
via LINQ che ho nella classe, ad esempio con un CommandButton,
e prima di uscire dall'evento click richiamo la routine che carica la
dataGrid aggiornandola.
 
Non ho milioni di dati, poco pi� di un migliaio che al massimo raddopiano.
 
Quello che mi serve in definitiva, � staccare la parte con le routine
dall'interfaccia. Posso avere interfacce diverse(controlli diversi),
in applicazioni diverse che si interfacciano allo stesso DataContext
(nel senso che il db � sempre quello e sempre quello � ci� che ho
come LINQ To SQL e DataContext).
 
Se questa strada non � percorribile, qual'� una logica
alternativa? Tenete presente, ancora una volta, che sto parlando
di un piccolo progetto che utilizza una window con un tab a tre schede
o tre windows separate, sempre con pochi(ma possono essere diversi per tipo)
controlli.
 
E tenete anche presente la quasi niubbit� di chi scrive... ;-)
 
Ancora grazie. Anche per la pazienza.
 
Elisabetta.
 
 
 

 Elisabetta.
 


 valore dopo che è stata disconnessa, scoppia tutto, giusto?
 
oh yes :-)
Adesso dico una cosa forte: il lazy loading è un anti-pattern ;-) e 
siccome tu non sei venuto al DDD Day adesso rosichi :-)



 
Non ho il problema di due utenti che modifichino
contemporaneamente il db.
 
Ma, provo di capire. Nel frattempo ho fatto prove
in un simil contesto(tre pc, diverse interfacce, SQL) e
non vedo particolari problemi.
 
Grazie per il tempo che mi hai dedicato.
 
Elisabetta. 
 
 

 siccome tu non sei venuto al DDD Day adesso rosichi :-)
LOL
 
-- 
.A
GUISA - 
http://www.guisa.org
 
UGIdotNET - 
http://www.ugidotnet.org
 
Read my blog at: 
http://blogs.ugidotnet.org/pape
 

 siccome tu non sei venuto al DDD Day adesso rosichi :-)
 
Do'h!!!
:-D
 
Ciao,
Giulio
 
-- 
 

 quando la capisci la eviti
 
Nella mia beata ignoranza, l'ho sempre evitata. :-)
 
Ciao,
Giulio
 
-- 
 
 

 non vedo particolari problemi.
 
non hai colto la prte che desideravo cogliessi, mea culpa.
la cosa importante, in un'applicazione desktop, ï¿œ che il ciclo di vita 
della transazione di business (la conversazione appunto) ï¿œ molto legato 
alla use case e non ï¿œ standardizzabile come invece ï¿œ abbastanza facile 
fare nel mondo web dove http detta le regole del goico.
 
.m



 
Forse invece ho capito.
Tre diversi pc ed un unico db.
Non ho mai la sicurezza assoluta di cosa
ci sia realmente nel db, a dispetto di cosa
ci sia negli oggetti dei relativi contesti.
 
Nel mio caso, due pc hanno solo accesso
in lettura ed uno in scrittura.
 
Elisabetta. 
 
 

 in lettura ed uno in scrittura.
 
allora è una passeggiata :-)
