[cdimauro]

Originariamente inviato da gugoXX

Non ho mai detto di rinunciare alle stored procedure.
Solo non vorrei vederle scritte nel linguaggio proprietario del DB di turno, che peraltro e' praticamente sempre un procedurale che puzza di vecchio (Con i controsensi che sto intuendo proprio in questo periodo dell'avere un linguaggio procedurale per gestire i dati strutturati di un DB)
E infatti sia in Oracle che in SqlServer (che sono tra i migliori, potete dire cosa volete), si possono scrivere StoredProcedure in Java nel primo, e in C# nel secondo.
Codice C# compilato, richiamabile dal C# di altri parti, debuggabile e testabile senza troppi problemi e con le possibilita' che permette tale linguaggio.
Sono pezzi di codice che vanno comunque a finire dentro il DB, ma scritti in un linguaggio che e' ben diverso dal PL/SQL o dal T-SQL.
Tutto all'interno della stessa soluzione, in progetti diversi, tanto che non ti sembra neppure di avere delle stored procedure.
E non ti sembra neppure di avere un database, dato che anche la definizione delle tabelle e delle viste si puo' fare "disegnando" un diagramma E-R, sempre in un opportuno modulo della soluzione.
Con la possibilita' non indifferente di usare, senza troppi salti mortali, i vari prodotti di SourceSafe, SubVersion & C.

Adesso il discorso cambia completamente e sono d'accordo. Tra l'altro è proprio l'orientamento degli engine SQL quello di integrare il supporto ai linguaggi di programmazione tradizionali.

E comunque non sarebbe neppure vero che il programmare in C# e basta genererebbe tanto traffico di rete.
Prima si', era facile cadere nella trappola. Ora con il LINQ non sarebbe piu' cosi' tanto vero, e lo sto sperimentando proprio in questi giorni.
Il motore LINQ genera al volo le istruzioni SQL da sottomettere al database, sono progettate per essere funzionali, e l'istruzione SQL viene generata tutta insieme e sottomessa al database senza dover scartare nulla, se l'ho sfruttata bene.

Non penso risolva pienamente il problema.

In una SP capita, ad esempio, di eseguire un ciclo su un certo numero n di record per poi lavorarci, scartarne alcuni e infine tornare soltanto gli m <= n i dati che servono.

Delegando all'esterno le operazioni, in ogni caso i dati degli n record dovranno essere prelevati dall'applicazione, elaborarli, e poi si dovranno eseguire eventuali altre m <= n query per recuperare le informazioni finali.

C'è un passaggio di dati inutile fra client e server: con le SP il primo riceve soltanto i dati che gli servono.

Non so se sono stato chiaro.

Ma sono d'accordo.
Sono stato tra i primi nell'azienda dove lavoravo prima a sfruttare il test driven development.
Pero' quello che appunto e' che se il linguaggio mi permette di fare meno test, tanto di guadagnato.
Ripeto, un test fatto bene in javascript dovrebbe controllare, per ciascuna funzione, la validita' di tutti i parametri.
E sono chili di codice di test che qualcuno deve scrivere, e che in C# non dovrebbe fare.
Se vado a leggere i test che sono stati fatti sul progetto in cui sto lavorando ora, sono tutti test che servono per coprire problemi a runtime, tipo valori inseriti o derivati dagli utenti o simili.
Se il linguaggio mi permette di avere meno errori a runtime, meno test dovro' scrivere.
Idem per le biforcazioni che suggerisci. E comunque il test dovrebbe essere scritto prima e a prescindere dalla implementazione dello sviluppatore, e idealmente da una persona diversa. Non dovresti sapere quali biforcazioni far fare ai test, dovrebbe essere tutto astratto.

E fai benissimo. In azienda da noi si usa uno stile di programmazione che si chiama Extreme Programming, uno dei cui pilastri e' proprio il test driven development.
Per come ci e' stato insegnato nei corsi iniziali, dopo la debita progettazione da parte degli architetti, i quali preparano anche i principali moduli da riempire, parte anche la QA. La QA e' il gruppo che si occupera' alla fine di ogni step, della Quality Assurance, ovvero in pratica a cercare i bachi.
Ma all'inzio di ogni step, intanto che non ha nulla da testare, dovrebbe (e dico dovrebbe perche' onestamente non lo fa quasi mai) scrivere i test per i vari moduli, indipendentemente dagli sviluppatori.
I quali aggiungeranno ovviamente i loro test, ma il concetto e' chiaro.

Mumble. Con la TDD ho imparato che prima si scrivono i test, e poi il codice (che, all'inizio, deve far fallire il test per indicare la condizione d'errore -> il requisito non soddisfatto oppure il bug che viene "esercitato").

Il codice non va progettato in maniera tradizionale: viene costruito in maniera evolutiva in base anche alle condizioni che, e lo sappiamo benissimo, cambiano col tempo.

Ecco qui http://martinfowler.com/articles/designDead.html un ECCELLENTE articolo sull'argomento. E' lunghetto, ma ne vale la pena.

for (int u=0;u<100;u++)
   Console.WriteLine(u);

Enumerable.Range(1,100).ForEach( t => Console.Writeline(t) );

Secondo me cosi' non si impara a programmare.
Troppe cose insieme, non sai cosa fa veramente la macchina.
Non mi sembra che risolvano il cocetto mentale di algoritmo.

Non c'è alcun bisogno di conoscere cosa fa "veramente" la macchina per imparare a programmare: i programmatori devono risolvere problemi, non studiarsi le architetture su cui girano le applicazioni (che tra l'altro possono anche cambiare).

A me sembra servirebbe di piu' partire proprio con
- il concetto di variabile
- di assegnazione di valori ad una variabile
- di if.then.else
- di goto

Poi posso sbagliare, non sono un professore.

Nooo. Ti prego, il goto nooooo!!!

IMHO bisogna partire dal concetto di dato, tipo di dato, operazione, condizione, e così via.