Eh già, sapevo che prima o poi avrei dovuto fermarmi a ragionare su questo aspetto ed alla fine è successo... Mi piace pensare al blog come ad un "vero" diario personale, da rispolverare dopo qualche mese per sorridere di quanto scritto in passato (ok, ok... voi potete già sorridere adesso 
) ed oggi mi sento in arteria per uno di questi resoconti migliari!
OOP:
Per me semplicemente è divenuto il dna della programmazione "vera"! Purtroppo non è da molto che conosco e metto in pratica in modo un pò approfondito il mondo dell'OO, ma per ora il concetto ha letteralmente pervaso il mio modo di sviluppare codice. Al momento per rinuciare ad un'unghia di OO dovrebbero offrirmi come minimo una super funzionalità IA eee anche in quel caso foorse...
Non posso dire di essere diventato un "seguace" dell'OOP semplicemente perchè penso di conoscere solo il 2% di questo mondo, ma al momento è come leggere le ultime 30 pagine di un libro di Asimov: ad ogni pagina inizia ad avere senso tutto ciò che hai letto fin lì ed il libro ti sembra fantastico ma, la pagina dopo, la sopresa è ancora più profonda ed il libro ti sembra ancora più fenomenale!
E devo ringraziare per l'ennesima volta davvero tutto UGIdotNET per questo, e sinceramente grazie grazie ed ancora grazie soprattutto all'ultra-paziente Andrea per le infinite domande che si è sciroppato dal sottoscritto! Non sono ancora riuscito a fargli dire "non lo so"...e mi sa che non ci riuscirò mai!
n-tier:
Importante... o meglio, molto utile in alcuni scenari applicativi e comunque comodo dal punto di vista della mantenibilità dell'applicazione. Utile anche per la gestione della sicurezza dell'applicazione ed in un certo senso forse anche nello sviluppo in team. Lo strato intermedio forse in alcune applicazioni più "piccole" al momento mi sembra più un overload di codice che un reale vantaggio, mentre il DAL, a prescindere dal reale interesse nel poter cambiare provider mi sembra comunque un "must" per i vantaggi che porta.
Ovviamente queste sono solo le mie impressioni attuali e con ogni probabilità tra qualche mese mi ritroverò a non essere d'accordo con quanto scritto, ma sono fatto così... Devo fare "miei" certi concetti per poterci "credere fino in fondo!".
Design (parolona, detta da uno come me!) vs. RAD:
E' uno dei dubbi amletici di chi sviluppa per lavoro quando le dimensioni dell'organizzazione e la forza lavoro sono ridotte, in quei casi in cui lo è altrettanto la richiesta del cliente.
"Voglio un programmINO che mi faccia semplicemente queste cosINE..."
Che fare? Quanto soffermarsi su design e pianificazione? Spesso si impiegherebbe meno a fare il software piuttosto che studiarne il design e metterlo giù. Ma poi?
Se si decide di svilupapre il software sacrificando la fase di analisi e questo raggiunge il suo obiettivo (fortunatamente sembra che capiti molto spesso ultimamente...) piace, anche troppo, al cliente ed a quel punto iniziano i problemi. Sul telaio di una pseudo 500 costruita senza un progetto ci troviamo man mano ad aggiungere "pezzi" sempre più "pesanti" e complessi. Il risultato è che inevitabilemte prima o poi il povero telaio della ex-500 sbrocca e quando succede non c'è modo di capire cosa abbia contribuito maggiormente e soprattutto come porre rimedio.
Morale? Anche secondo me è sempre meglio fermarsi prima e buttare giù un minimo di schema quantomeno dell'architettura del progetto; magari in UML... altro "strumento" che purtroppo credo di non utilizzare (e soprattutto comprendere) ancora correttamente...
I dubbi:
So che la soluzione di moltissimi dei miei dubbi sarà in quei libri che devo (porca miseriaccia... DEVO!) riuscire a leggere al più presto, ma nel frattempo il lavoro deve proseguire e quindi mi trovo ad affrontare i dubbi e le riflessioni a "mani nude". Meno male che, anche in questo caso, c'è la pazienza degli UGIdotNETtiani che ogni tanto ci soccorre nei momenti difficili (una sorta di "Operatore" in Matrix!).
A dire il vero, comunque, affrontare prima il problema con la mia testa e poi conoscere la soluzione "seria" offerta dall'esperienza di qualcuno, sia in un libro o in un post, mi ha sempre aiutato a capire meglio l'argomento ed apprezzarne maggiormente la soluzione.
Prendiamo un esempio reale: transazioni ed architettura n-tier...
Che bella invenzione le transazioni! Ti preoccupi "solo" di prepararla come si deve... Tiri su tutto il polverone che vuoi e se qualcosa va storto ci pensa lei a rimettere tutto in ordine! Potessi farlo anche nel mio ufficio... (e magari anche in IIS... , meno male che arriva Whidbey con Cassini!)
Ok, si, lo so... non funziona proprio così con le transazioni... ma è solo una frase detta per entrare in argomento!
Immaginiamo un metodo InsertOrder fornito dal Data Access Layer che esegua le operazioni necessarie ad inserire un ordine, quindi con una INSERT dell'ordine, quelle per il dettaglio ecc. ecc.
Sfruttare le potenzialità delle transazioni in uno scenario di questo tipo da grandi soddisfazioni col minimo sforzo, ma cosa succede se l'inserimento di un ordine contempla operazioni esterne al DAL, come ad esempio l'invio di mail o l'inserimento in code di messaggi o magari più in generale di esecuzione di metodi contenuti, per esempio, nel Business Layer (quindi per definizione sconosciuto agli strati sottostanti)? Magari l'inserimento dell'ordine non è valido se non completa tutti i passaggi di business e quindi dobbiamo "annullare" tutta l'operazione in corso. La transazione a livello di DAL non ci basta più e per questo tipo di scenario dobbiamo creare noi una sorta di transazione.
Insomma, questo tanto per dire che di dubbi uno come me ne ha sempre di più. Il mio motto ormai da qualche anno è "Più cose impari, più cose scopri non di non sapere!" e sembra che per molto tempo ancora dovrà essere il mio cavallo di battaglia.
...speriamo!