[.NET] elenco tecnologie

[Gelert]

Devo realizzare alcuni progetti per l'università, i miei professori insegnano solo le tecnologie Java e Java EE ma accettano progetti anche nelle tecnologie .NET

Io vorrei iniziare a studiare le tecnologie .NET per ampliare le conoscenze e sfrutto l'occasione ma i professori non danno alcun aiuto su queste tecnologie.

mi servirebbe un elenco delle tecnologie che posso usare in ambito .NET con una breve descrizione (davvero minima) e magari un indicazione su testi buoni per conoscerle

in particolare mi servirebbero le tecnologie per la realizzazione di web application

P.S. chiedo scusa per il doppio topic ma avevo scordato le parentesi quadre nel titolo

[tomminno]

Originariamente inviato da Gelert

in particolare mi servirebbero le tecnologie per la realizzazione di web application

Diciamo che le applicazioni web in .NET sono coperte da: ASP.NET, ASP.NET MVC, Silverlight, WCF.
ASP.NET è la tecnologia base, fa intensivo uso di automatismi per la realizzazione delle pagine grazie all'ausilio di Visual Studio.
ASP.NET MVC è un fork in quanto porta il paradigma MVC in ASP.NET, si tendono ad usare molto meno gli automatismi per tornare al vecchio spaghetti code. Personalmente lo trovo molto complicato (rispetto a ASP.NET standard) e non giustificato in piccoli applicativi web.
Silverlight è dedicato all'integrazione tra web e multimedia oltre ad avvicinare lo sviluppo desktop con quello web, vuole essere un concorrente di flash.
WCF è il framework dedicato ai webservice, settore già parzialmente coperto da ASP.NET.

Libri? Sinceramente non saprei quelli che ho trovato io erano praticamente un elenco del tutto inutile di tutte le funzionalità (penso a quelli della Wrox), per provarle tutte uno finirebbe per impiegare anni, da usare più come manuale di consultazione che per lo studio.

[Gelert]

ok tutto chiaro, quindi volendo utilizzare .NET dovrei studiare C# (che dovrebbe convenirmi, visto che provengo da java, rispetto a Visual Basic .NET che posso sempre imparare dopo) e ASP .NET

per fare qualcosa di più avanzato Silverlight, WCF e ASP .NET MVC.

però diciamo qui siamo molto sul generico sulle tecnologie, entrando più nello specifico negli strumenti?

non so per esempio il professore mi ha detto di usare almeno il .NET Entity Framework oppure LINQ per le connessioni al database. mi serviva una panoramica sugli strumenti consigliati per realizzare applicazioni (in particolare applicazioni WEB ma non solo) con una brevissima descrizione delle funzioni.

[khelidan1980]

Originariamente inviato da tomminno

ASP.NET MVC è un fork in quanto porta il paradigma MVC in ASP.NET, si tendono ad usare molto meno gli automatismi per tornare al vecchio spaghetti code.

L'applicazione del pattern MVC porta allo "spagehtti code"? Questa mi mancava

[tomminno]

Originariamente inviato da khelidan1980

L'applicazione del pattern MVC porta allo "spagehtti code"? Questa mi mancava

Per me un ciclo for che spara fuori l'html è spaghetti code e con ASP.NET MVC è spesso più indicato questo tipo di utilizzo piuttosto che non i controlli server side tipici di ASP.NET perchè i postback scatenati da questi non passano per l'action controller dell'MVC.

[nico159]

Originariamente inviato da tomminno

Per me un ciclo for che spara fuori l'html è spaghetti code e con ASP.NET MVC è spesso più indicato questo tipo di utilizzo piuttosto che non i controlli server side tipici di ASP.NET perchè i postback scatenati da questi non passano per l'action controller dell'MVC.

Ma ASP.NET MVC non usa un template engine?

[fero86]

Originariamente inviato da tomminno

Per me un ciclo for che spara fuori l'html è spaghetti code

perché?

[nuovoUtente86]

Originariamente inviato da fero86

perché?

infatti perchè?

[tomminno]

Originariamente inviato da nuovoUtente86

infatti perchè?

Perchè stai mischiando codice e presentazione.
Il for o foreach lo fai su un contenitore dati che quindi deve essere nella visibilità della presentazione e difficilmente la valorizzazione di questo contenitore può avvenire in luoghi diversi dalla presentazione che comporta altro codice non strettamente legato alla visualizzazione.

Nel caso specifico ASP.NET si riduce a niente di molto diverso da ASP.

[nuovoUtente86]

Originariamente inviato da tomminno

Perchè stai mischiando codice e presentazione.
Il for o foreach lo fai su un contenitore dati che quindi deve essere nella visibilità della presentazione e difficilmente la valorizzazione di questo contenitore può avvenire in luoghi diversi dalla presentazione che comporta altro codice non strettamente legato alla visualizzazione.

Nel caso specifico ASP.NET si riduce a niente di molto diverso da ASP.

Lo "spaghetti code" riferisce la complessità e disorganizzazione del flusso di un programma e non ha nulla a che vedere con l' architettura, e non è ammissibile considerare un for "" spaghetti code", come lo sarebbe viceversa un go-to.
Sempre se parliamo di architettura è sicuramente preferibile, in fatto di strutturazione a livelli, l' architettura MVC, piuttosto che quella ad un livello (più un wrapper per ADO.NET) offerta dai controlli server-side presenti in ASPX.
Ed inoltre nel modello MVC, la view è solo l' utilizzatore finale, dei dati ad essa pushiati dal model, per intermezzo di un controller

[Kralizek]

in realtá mi trovo d'accordo con tommino, usando tecniche di programmazione adatte, la programmazione attraverso ASP.NET/WebForm riesce a raggiungere livelli di pulizia del codice eccellenti.

Se si utilizza la Page solo come un dispatcher "stupido" (ma "state-ful") degli eventi ricevuti dal client, e confini la logica applicativa alle classi di Business Layer, alla fine riesci ad ottenere la pulizia del codice tipica del pattern MVC con la potenza dei controlli e dei loro eventi.

Certo, la peculiaritá dell'MVC é il fatto che é impossibile scrivere porcherie (oddio, ci si riesce sempre), ma WebForm ha una potenza espressiva che MVC si sogna, imho.

Certo se si usano porcherie come l'SqlDataSource o cose del genere (popolare una GridView in Page.PreRender, visto fare oggi, stavo per azzannare al gargarozzo il tipo), citando lo scarafaccio stercoraro "c'é poca merda da fare a pallottole".

[tomminno]

Originariamente inviato da nuovoUtente86

Lo "spaghetti code" riferisce la complessità e disorganizzazione del flusso di un programma e non ha nulla a che vedere con l' architettura, e non è ammissibile considerare un for "" spaghetti code", come lo sarebbe viceversa un go-to.

Nella programmazione web lo spaghetti code indica la tendenza dei linguaggi di scripting a mischiare codice e presentazione.

Sempre se parliamo di architettura è sicuramente preferibile, in fatto di strutturazione a livelli, l' architettura MVC, piuttosto che quella ad un livello (più un wrapper per ADO.NET) offerta dai controlli server-side presenti in ASPX.

Veramente anche in ASP.NET si sviluppa normalmente a 3 livelli dove la presentazione è composta da la parte asp.net + code behind, poi hai gli altri 2 livelli classici. Poi ovviamente si può sempre "sbagliare" la strutturazione.

Ed inoltre nel modello MVC, la view è solo l' utilizzatore finale, dei dati ad essa pushiati dal model, per intermezzo di un controller

In ASP.NET MVC il controller gestisce gli eventi che arrivano dal web server, poi però ti ritrovi la pagina con qualcosa di simile:

<%if (ViewData.Model.Data == null) %>
Nessun dato disponibile
<%else {
foreach (Models.Data d in ViewData.Model.Data){ %>
<tr>
  <td>d.Field1</td>
  <td>d.Field2</td>
  <td>d.Field3</td>
</tr>
<%}}%>

Non poi tanto differente dal vecchio ASP non ti pare?

[nuovoUtente86]

Originariamente inviato da tomminno

Nella programmazione web lo spaghetti code indica la tendenza dei linguaggi di scripting a mischiare codice e presentazione.

è una tua personale interpretazione del termine. Per carità il linguaggio è una convenzione, basta mettersi d' accordo, ma bisogna anche sapere che con l' espressione originale non ha nulla a che vedere.

Veramente anche in ASP.NET si sviluppa normalmente a 3 livelli dove la presentazione è composta da la parte asp.net + code behind, poi hai gli altri 2 livelli classici. Poi ovviamente si può sempre "sbagliare" la strutturazione.

molti, troppi dei lavori in ASPX.NET sono costruiti ad un livello attraverso SQLDATASOURCE e compagnia allegra, perchè rappresentano un semplificazione, nell' immediato, per chi ha poca voglia di lavorare.

In ASP.NET MVC il controller gestisce gli eventi che arrivano dal web server, poi però ti ritrovi la pagina con qualcosa di simile:

<%if (ViewData.Model.Data == null) %>
Nessun dato disponibile
<%else {
foreach (Models.Data d in ViewData.Model.Data){ %>
<tr>
  <td>d.Field1</td>
  <td>d.Field2</td>
  <td>d.Field3</td>
</tr>
<%}}%>

Non poi tanto differente dal vecchio ASP non ti pare?

Il flusso applicativo non è ingarbugliato, ed il pattern MVC, specifica che il controller indichi cosa se ne debba fare dei dati, il come è carico della View, e ciò deriva dal fatto che lo strato presentazione conosce (può conoscere) direttamente quello di logica, ma il contario non è lecito.

[Kralizek]

molti, troppi dei lavori in ASPX.NET sono costruiti ad un livello attraverso SQLDATASOURCE e compagnia allegra, perchè rappresentano un semplificazione, nell' immediato, per chi ha poca voglia di lavorare.

si fanno tante porcherie anche in C, lo buttiamo?

Il flusso applicativo non è ingarbugliato, ed il pattern MVC, specifica che il controller indichi cosa se ne debba fare dei dati, il come è carico della View, e ciò deriva dal fatto che lo strato presentazione conosce (può conoscere) direttamente quello di logica, ma il contario non è lecito.

prova a pensare ad una View realizzata con ASP.NET WebForm ancora più pulita

[Gelert]

ragazzi siete andati un pochino fuori tema: a me interessava sapere su quali tecnologie concentrarmi per realizzare un'applicazione web e quali strumenti ho a disposizione.

[Kralizek]

Originariamente inviato da Gelert

ragazzi siete andati un pochino fuori tema: a me interessava sapere su quali tecnologie concentrarmi per realizzare un'applicazione web e quali strumenti ho a disposizione.

siamo perfettamente IT! ci stiamo scannando per decidere su cosa consigliarti di focalizzarti!

[nuovoUtente86]

Originariamente inviato da Kralizek

si fanno tante porcherie anche in C, lo buttiamo


prova a pensare ad una View realizzata con ASP.NET WebForm ancora più pulita

in quel caso si tratta esclusivamente di errori programmatici, non dettati dal linguaggio, mentre ASP offre il fianco alla stesura di applicazioni magari formalmente molto pulite (più pulite se vogliamo di altri architetture) ma con falle strutturali evidenti.

[tomminno]

Originariamente inviato da nuovoUtente86

è una tua personale interpretazione del termine. Per carità il linguaggio è una convenzione, basta mettersi d' accordo, ma bisogna anche sapere che con l' espressione originale non ha nulla a che vedere.

Veramente è comunemente chiamato così, non è una mia interpretazione.
Ci sono tonnellate di pagine in internet sullo spaghetti code in PHP.

molti, troppi dei lavori in ASPX.NET sono costruiti ad un livello attraverso SQLDATASOURCE e compagnia allegra, perchè rappresentano un semplificazione, nell' immediato, per chi ha poca voglia di lavorare.

E questo che c'entra? Oltretutto li puoi usare solo in abbinamento con SqlServer.
Il fatto che un linguaggio consenta delle semplificazioni per via automatica lo rende automaticamente per sfaticati che non hanno voglia di lavorare?

Non è mica scritto sulla pietra che se devo mostrare i dati di una tabella debba per forza impegare un giorno di lavoro per tirare su tutto il necessario per un MVC, quando posso ottenere lo stesso risultato in 10 secondi netti.

Preciso che io non ho mai usato gli SqlDataSource e non ho mai lavorato su un sito che li adottasse, ma forse è perchè non mi è mai capitato di dover semplicemente mostrare i dati di una tabella, se mai dovesse capitare non li schiferei di certo.

Il flusso applicativo non è ingarbugliato, ed il pattern MVC, specifica che il controller indichi cosa se ne debba fare dei dati, il come è carico della View, e ciò deriva dal fatto che lo strato presentazione conosce (può conoscere) direttamente quello di logica, ma il contario non è lecito.

Si prova a completarlo con codice di una pagina un minimo complessa, chessò con controlli tipo checkbox o dropdown o button all'interno delle celle il cui stato o visualizzazione dipende dal contenuto di altre variabili.
Poi vediamo quanto il codice della View risulta lineare...
Infine prova a farne il refactoring.

[tomminno]

Originariamente inviato da nuovoUtente86

in quel caso si tratta esclusivamente di errori programmatici, non dettati dal linguaggio, mentre ASP offre il fianco alla stesura di applicazioni magari formalmente molto pulite (più pulite se vogliamo di altri architetture) ma con falle strutturali evidenti.

Quali?
Il fatto che ci siano strumenti come SqlDataSource che possono essere usati male, non significa che ci siano falle strutturali.
Altrimenti tutti i linguaggi di scripting sono automaticamente da scartare perchè è possibile scrivere tutto il codice nella stessa pagina. Ma estendendo il discorso anche in Java e C# puoi scrivere un programma completamente nel Main oppure che utilizza tutti metodi statici richiamati dal Main. Cos'è risultano linguaggi da scartare perchè consentono una programmazione in stile procedurale?

Secondo me l'unica falla, ma che oggi risulta del tutto superata, è il fatto di necessitare obbligatoriamente dei javascript per funzionare.
Ma oggi uno che gira senza javascript abilitati si perde praticamente tutta la modernità del web.
Infine un altro elemento a sfavore è che gli automatismi in qualche raro caso mostrano tutti i loro limiti: ad esempio in questi giorni mi è capitato di dover replicare lo stile di una tabella di Sharepoint, ogni cella della tabella era costituita da 12000 caratteri (si 12Kb per ogni cella di una tabella con centinaia di elementi ) e i controlli standard non risultavano adatti per via della complessità del codice da generare, ho dovuto crearmi dei controlli custom che generassero l'html desiderato, ma erano in ogni caso ben utilizzabili via codice, e soprattutto facilmente rifattorizzabili in caso di modifiche.