Design Patterns

[NeXuS26]

Salve ragazzi, ho un dubbio sull'implementazione di un progetto (in vb .net), giusto x dare una visione d'insieme, il software deve provvedere ad inserire,cercare,modificare..etc.. "offerte" di tipo commerciale ad aziende (si presume, interessate..:P) per cui ci saranno le tabelle "offerte"..."aziende"..."periodi(per le quali le offerte saranno valide)".."contatti" etc...etc...
ora, mi chiedo, nel data layer dell'applicazione, si inseriscono i componenti adibiti all'accesso fisico ai dati, e fin qui ci siamo. ma è corretto, secondo voi, inserire qui pure le funzioni del tipo, detto in sql "select * from offerte where idCompany = ?parametro" ? non andrebbero messe nel business layer?
a rigor di logica (la mia:P) nel dl dovrebbero andarci giusto componenti generici di accesso al datasource, del tipo "testa la connessione" "costruisci la stringa" "esegui la query" ...no?
i miei progetti fino a poco fa erano giusto a mio uso e consumo(quasi), mi piaceva giusto fondermi il cervello con algoritmi di qualche tipo, e le uniche cose che mi imponevo erano che il programma funzionasse, e che lo facesse velocemente, e se dovevo modificare il codice di qualcun altro, quanto + era scritto male, tanto + mi divertiva provare a comprenderlo. ma ora c'è il team...e sto vb del caxxo che è orribile.. mi tocca studiarmi i design pattern se ci voglio pure mangiare con sto lavoro:P

[devbeginner]

Originariamente inviato da NeXuS26

Salve ragazzi, ho un dubbio sull'implementazione di un progetto (in vb .net), giusto x dare una visione d'insieme, il software deve provvedere ad inserire,cercare,modificare..etc.. "offerte" di tipo commerciale ad aziende (si presume, interessate..:P) per cui ci saranno le tabelle "offerte"..."aziende"..."periodi(per le quali le offerte saranno valide)".."contatti" etc...etc...
ora, mi chiedo, nel data layer dell'applicazione, si inseriscono i componenti adibiti all'accesso fisico ai dati, e fin qui ci siamo. ma è corretto, secondo voi, inserire qui pure le funzioni del tipo, detto in sql "select * from offerte where idCompany = ?parametro" ? non andrebbero messe nel business layer?
a rigor di logica (la mia:P) nel dl dovrebbero andarci giusto componenti generici di accesso al datasource, del tipo "testa la connessione" "costruisci la stringa" "esegui la query" ...no?

sì è corretto, poi dipende anche dal modello architetturale che influenza giocoforza le tue scelte tecnologiche.
Dato che sei in ambito .NET, IMHO, tanto vale che implementi la logica di accesso ai dati con LINQ e sottoforma magari di servizi (WCF).

i miei progetti fino a poco fa erano giusto a mio uso e consumo(quasi), mi piaceva giusto fondermi il cervello con algoritmi di qualche tipo, e le uniche cose che mi imponevo erano che il programma funzionasse, e che lo facesse velocemente, e se dovevo modificare il codice di qualcun altro, quanto + era scritto male, tanto + mi divertiva provare a comprenderlo.

non credo fossi pagato per perdere tempo a divertirti

ma ora c'è il team...e sto vb del caxxo che è orribile..

VB del vecchio VB6 non ha praticamente nulla, a parte qualche keyword similare. E' comunque sempre .NET

mi tocca studiarmi i design pattern se ci voglio pure mangiare con sto lavoro:P

perché senza design pattern prima come facevi?


sempre perché lavori in ambito .NET...pensate di usare degli ORM?
Perché sia con NHibernate che Entity Framework è possibile implementare il Repository Pattern...se ricordo bene da studi recenti non è uno dei classici pattern elaborati nella Gang of Four ma deriva piuttosto dalla letteratura del Domain Driven Design...