Buongiorno a tutti.
Vorrei conoscere il vostro parere in merito alle questione in oggetto. E cioè...Cosa ne pensate di un progetto web basato su DomainModel (o quasi) che per la persistenza usa un DataLayer formato da classi composte solo da metodi statici?Una serie di classi (xxxDataManager) che gestiscono l'accesso alla base dati per i vari oggetti di business ereditando da una classe base che definisce i metodi comuni di accesso al db che in questo caso utilizzano DAAB come "layer finale" di accesso alla base dati.Provo a spiegarmi meglio con un banale esempio:public class DALBASE{ protected static Database CreateDatabase(){...} protected static Int32 ExecuteNonQuery(...){...}...}public class LibroDataManager:DALBASE{ public static Libro Getlibro(Int32 IdLibro){...}}
Grazie in anticipo, ciao.
Ciao,
penso che l'approccio concettualmente sia quello giusto ma soffre di un grosso problema, proprio concettuale, e cioè che non c'è ereditarietà per i membri statici.
Inoltre puro consiglio, molto spassionato, perchè farsi del male? hai un Domain Model, tutta la vita un ORM, ma proprio tutta la vita.
.m
Concordo con Mauro, un orm è la soluzione migliore. Per quanto riguarda la domanda dei metodi statici, la cosa che uso molto spesso è fare una struttura del genere
public interface IRepository<T> {
public T GetByKey(..)
public class NHibernateRepository<T> {
ora la cosa migliore è che qualsiasi oggetto necessiti di un repository dichiari una dipendenza tipo
public class HoBisognoDelRepository {
public IRepository<Customer> CustomerRepository {get; set;}
e fai risolvere l'oggetto da Castle o da qualsiasi libreria di inversione di contrllo. In questo modo ottieni flessibilità, semplicità di utilizzo e sopratutto Testabilità
Se l'oggetto non può proprio essere risolto puoi fare una classe statica tipo
public static class Repository<T> {
private static Repository<T> instance = IoC.Resolve<IRepository<T>>();
public static T GetByKey(object key) {
return instance. GetByKey(key)
}
alk.
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
Ciao a tutti e grazie per le risposte.
Mauro Servienti:Ciao,penso che l'approccio concettualmente sia quello giusto ma soffre di un grosso problema, proprio concettuale, e cioè che non c'è ereditarietà per i membri statici.Inoltre puro consiglio, molto spassionato, perchè farsi del male? hai un Domain Model, tutta la vita un ORM, ma proprio tutta la vita..m
Perdonami Mauro credo di aver frainteso. Puoi farmi un esempio sul problema concettuale? Cosa intendi con "non c'è ereditarietà"?Preciso quello che ho detto prima perchè in realtà la classe base viene definita solo come come classe di raccolta di metodi helper per darmi la possibilità di poter chiamare un ExecuteNonQuery(...) o Un ExecuteScalar<Int32>(...) dalla mia classe Manager DAL con molta facilità.
Gian Maria Ricci:Concordo con Mauro, un orm è la soluzione migliore. Per quanto riguarda la domanda dei metodi statici, la cosa che uso molto spesso è fare una struttura del genere...
Avete sicuramente ragione ho bisogno di approfondire per capire dove sta il nodo della questione...Solo a "sensazione" ci sono cose che nom mi convincono anche perchè ho avuto occasione di usare lo stesso codice da un servizio WCF e sto avendo un po' di problemi... vi spiego però perchè avevo preso questa strada:L'applicazione per adesso esegue piu che altro delle letture dei dati.Alcune delle scritture più importanti vengono per adesso eseguite da processi esterni, appunto da servizi WCF(+MSMQ) che dovrebbero utilizzare lo stesso DAL.Lato web ho soprattutto molte query; stessi oggetti di business letti molte volte con sistemi diversi (chiavi e filtri diversi) e comunque la mappatura tra db e BusinessObject non è particolarmente complessa. Una applicazione che si occupa per adesso più che altro di analisi dei dati. Ho usato il domain model al posto di strutture dati preconfezionate (datatable,dataset) perchè comunque mi è utile per l'analisi che non è costituita solo da classici report.Ho pensato che per questa parte avrei sprecato inutilmente risorse utilizzando un ORM (session ecc...) e magari mi sarei ritrovato a scrivere comunque oggetti "custom" per l'accesso alla base dati per utilizzarli su reportistica, analisi, grafici ecc...ed avere codice più performante.Pensavo di introdurre successivamente un ORM con l'arrivo di oggetti che necessitano delle classiche operazioni CRUD.Ragionamento totalmente errato?
4Net: Ciao a tutti e grazie per le risposte. Mauro Servienti:Ciao,penso che l'approccio concettualmente sia quello giusto ma soffre di un grosso problema, proprio concettuale, e cioè che non c'è ereditarietà per i membri statici.Inoltre puro consiglio, molto spassionato, perchè farsi del male? hai un Domain Model, tutta la vita un ORM, ma proprio tutta la vita..m Perdonami Mauro credo di aver frainteso. Puoi farmi un esempio sul problema concettuale? Cosa intendi con "non c'è ereditarietà"?Preciso quello che ho detto prima perchè in realtà la classe base viene definita solo come come classe di raccolta di metodi helper per darmi la possibilità di poter chiamare un ExecuteNonQuery(...) o Un ExecuteScalar<Int32>(...) dalla mia classe Manager DAL con molta facilità.
il problema è che se da una classe derivata volessi fare l'override di uno dei metodi statici semplicemente non puoi, non ha senso fare l'override di un metodo statico. Quindi questo ti poterebbe all'impossibilità di avere la ridefinizione di un comportamento cosa che è alla base della programmazione OO
4Net:Avete sicuramente ragione ho bisogno di approfondire per capire dove sta il nodo della questione...Solo a "sensazione" ci sono cose che nom mi convincono anche perchè ho avuto occasione di usare lo stesso codice da un servizio WCF e sto avendo un po' di problemi... vi spiego però perchè avevo preso questa strada:L'applicazione per adesso esegue piu che altro delle letture dei dati.Alcune delle scritture più importanti vengono per adesso eseguite da processi esterni, appunto da servizi WCF(+MSMQ) che dovrebbero utilizzare lo stesso DAL.Lato web ho soprattutto molte query; stessi oggetti di business letti molte volte con sistemi diversi (chiavi e filtri diversi) e comunque la mappatura tra db e BusinessObject non è particolarmente complessa. Una applicazione che si occupa per adesso più che altro di analisi dei dati. Ho usato il domain model al posto di strutture dati preconfezionate (datatable,dataset) perchè comunque mi è utile per l'analisi che non è costituita solo da classici report.Ho pensato che per questa parte avrei sprecato inutilmente risorse utilizzando un ORM (session ecc...) e magari mi sarei ritrovato a scrivere comunque oggetti "custom" per l'accesso alla base dati per utilizzarli su reportistica, analisi, grafici ecc...ed avere codice più performante.Pensavo di introdurre successivamente un ORM con l'arrivo di oggetti che necessitano delle classiche operazioni CRUD.Ragionamento totalmente errato?
se sei in un'applicazione web non hai un gran che di overhead dovuto alla sessione perchè la butti ad ogni response quindi il problema non si pone.
Ri-Ciao..
Mauro Servienti:il problema è che se da una classe derivata volessi fare l'override di uno dei metodi statici semplicemente non puoi, non ha senso fare l'override di un metodo statico. Quindi questo ti poterebbe all'impossibilità di avere la ridefinizione di un comportamento cosa che è alla base della programmazione OO
Mauro Servienti:...se sei in un'applicazione web non hai un gran che di overhead dovuto alla sessione perchè la butti ad ogni response quindi il problema non si pone. .m
Grazie.
Ciao.
In Nhibernate il costo maggiore si ha nella creazione della SessionFactory, quando effettivametne vengono analizzati i mapping e quindi si generano le classi proxy etc etc. Una volta fatto questo la creazione di una sessione è un operazione molto leggera. Anche in situazioni semplici, un ORM può comunque semplificare di molto la vita, e comunque ti permette di ridurre drasticamente il quantitativo di codice da mantenere, con il supporto di LINQ è anche facile fare query che possano poi essere modificate da un tool di refactoring etc.
Alk.