giorgio.novello wrote:
Nessun affronto, per l'amor di Dio.
Quello che noto è che nessuno di voi si permette di sindacare su quanto Microsoft pro-im/pone.
evidentemente non leggi nessuno dei nostri blog, altrimenti l'avresti notato.
A volte lavorare su un set di dati connesso semplifica la stesura del software e i relativi bug che ne seguono.
Sempre più spesso su web occorre fare delle elaborazioni complesse e non dei semplici accessi disconnessi e per questo che utilizzo ADOc.
lavorare con LINQ to SQL o in maniera Object Oriented, di fatto, è lavorare in maniera disconessa. per cui non capisco esattamente a cosa ti riferisci.
Riguardo alle classi generate da Linq Designer mi sfugge il problema: se aggiungo un campo ad una tabella e questo è una chiave devo rielaborare il tutto; mi chiedo dov'è il vantaggio di Linq perchè spesso durante lo sviluppo colonne che fungono da flag o piccole dimenticanze sono all'ordine del giorno e non è pansabile che su carta si faccia il lavoro al 100%.
e quindi se ti serve aggiungi la nuova colonan con il magging a mano. probabilmente tu utilizzi un approccio database-driven, ma non tutti lo fanno, perchè se devo modellare la logica di un'applicazione, trovo del tutto sbagliato partire da un dettaglio, che è lo storage. in quest'ottica, ribadisco, sarebbe stato errato fare in modo che il mapping fosse auto aggiornante. d'altra parte è così: quando tu fai il mapping, anche se magari non ci hai mai pensato, stipuli un contratto tra la classe generata ed il database di destinazione. se uno dei due vuole cambiare, il contratto va rotto. è così anche nei servizi ed è logico che sia così, lo ribadisco.
Non sembra una bestemmia, tanto è vero che a livello di flow Linq è simile ad ADOc quando di fanno le addnew, le update e le delete. Se microsoft ha fatto questa scelta, vuol dire che il paradigma è valido.
non lo trovo per niente simile ad ADO, visto che LINQ to SQL lavora con entità e con un DataContext, non con una query. non confondiamo le caratteristiche di ORM che ha LINQ to SQL con tutto il resto. ADO e LINQ to SQL sono semplicemente imparagonabili perchè non lo sono ASP e ASP.NET. ASP usa VBScript, che è interpretato e senza tipizzazione. ASP.NET sfrutta il ..NET Framework, ha la possibilità di usare l'OOP e linguaggi strongly-typed. c'è un abisso. punto.
Inotre leggo in giro che il numero di sviluppatori su base MS è sceso in questi anni a vantaggio di Java. Un motivo ci sarà.
veramente è esattamente il contrario, perchè prima Microsoft non aveva un'offerta per il mercato enterprise, quello grande, quello dove si muove il fatturato. ASP è semplicemente ridicolo in questo segmento, perchè con le webclass fai presto a stufarti. da quando c'è ASP.NET il .NET Framework ha rubato, come è ovvio che sia, sviluppatori a Java, non a Classic ASP, perchè sono simili negli obiettivi. non so esattamente dove hai letto questa cosa, ma sarei curioso di dare un'occhiata.
