[Sviluppo WEB] .net vs java

[Freaxxx]

sento spesso parlare del confronto .net contro java, in parole povere il confronto si riduce a parlare sempre degli stessi termini:
- portabilità
- semplicità di programmazione e conseguentemente maggiore velocità di produzione
- costi di produzione di un servizio o tot servizi

adesso vorrei fare la classica domanda che spariglia tutto: perché nessuno cita mai python ?

Abbiamo ad esempio la più grande società fornitrice di servizi web, per altro gratuiti nella stragrande maggioranza dei casi, ma questo rientra nello schema più grande dell'advertising che nel mondo tecnico informatico, che usa python per la qualsiasi cosa.

è difficile da gestire python ? è difficile da imparare ?

[Ludo237]

sinceramente non l'ho mai usato però sarei curioso di sapere com'è !

ps: preferisco .net a java per lo sviluppo in TODO (desktop / cloud / webapp / webservices eccecc)

[cdimauro]

Originariamente inviato da Freaxxx

sento spesso parlare del confronto .net contro java, in parole povere il confronto si riduce a parlare sempre degli stessi termini:
- portabilità
- semplicità di programmazione e conseguentemente maggiore velocità di produzione
- costi di produzione di un servizio o tot servizi

adesso vorrei fare la classica domanda che spariglia tutto: perché nessuno cita mai python ?

Per una questione di diffusione.

Abbiamo ad esempio la più grande società fornitrice di servizi web, per altro gratuiti nella stragrande maggioranza dei casi, ma questo rientra nello schema più grande dell'advertising che nel mondo tecnico informatico, che usa python per la qualsiasi cosa.

Si saranno fatti i loro conti.

è difficile da gestire python ?

No.

è difficile da imparare ?

L'esatto contrario.

[dojolab]

Originariamente inviato da Freaxxx

sento spesso parlare del confronto .net contro java, in parole povere il confronto si riduce a parlare sempre degli stessi termini:
- portabilità
- semplicità di programmazione e conseguentemente maggiore velocità di produzione
- costi di produzione di un servizio o tot servizi

adesso vorrei fare la classica domanda che spariglia tutto: perché nessuno cita mai python ?

Abbiamo ad esempio la più grande società fornitrice di servizi web, per altro gratuiti nella stragrande maggioranza dei casi, ma questo rientra nello schema più grande dell'advertising che nel mondo tecnico informatico, che usa python per la qualsiasi cosa.

è difficile da gestire python ? è difficile da imparare ?

Guarda, esperienza diretta: lavoro in ambito web app da molti anni oramai, prima tramite cgi (C) e poi con php; da un annetto mi sono avvicinato a Python con django e, a parte l'inizio un pò duretto, per il resto è una figata colossale , oltre che Python è veramente un bel linguaggio; peccato sia poco richiesto in ambito enterprise e lavorativo (salvo in qualche azienda, tra cui una molto grossa Italiana di cui non posso fare il nome).

Imparare Python? Una vaccata se hai dei rudimenti di programmazione, OOP principalmente (magari VB.NET proprio).

Quindi .net e Java sono giustamente delle tecnologie a cui bisogna puntare per 'lavorare'. Io le ho provate entrambi e, sinceramente, .net l ho trovato più pulito di Java per quanto riguarda asp.net stesso e lo sviluppo di Web App.

Dove non mi è piaciuto .net? In IIS, nella sua gestione/configurazione, nel deploy dell'app., nalla configurazione di SQL Server, ecc. (troppe GUI, mi sono perso) e nel discorso licenze (ma è a parte).

Quindi io ho optato per Java, dove con Apache-Tomcat (0 licenze e semplice da configurare) e dbms come pgsql e firebird posso ottenere eccellenti risultati. Poi se voglio esagerare sulla macchina di test... ho pure Oracle che con JDBC va a nozze.

[Sisupoika]

Originariamente inviato da Freaxxx

sento spesso parlare del confronto .net contro java, in parole povere il confronto si riduce a parlare sempre degli stessi termini:
- portabilità
- semplicità di programmazione e conseguentemente maggiore velocità di produzione
- costi di produzione di un servizio o tot servizi

adesso vorrei fare la classica domanda che spariglia tutto: perché nessuno cita mai python ?

Abbiamo ad esempio la più grande società fornitrice di servizi web, per altro gratuiti nella stragrande maggioranza dei casi, ma questo rientra nello schema più grande dell'advertising che nel mondo tecnico informatico, che usa python per la qualsiasi cosa.

è difficile da gestire python ? è difficile da imparare ?

Se parliamo di web development direi che sia .NET che Java sono tecnologie old-fashioned che non hanno nulla a che vedere con la produttivita' di frameworks come Rails (Ruby) e Django (Python) a causa della troppa configurazione e del processo di sviluppo troppo "pesante" e lento.

Purtoppo sono ancora molto popolari soprattutto presso corporates che preferirebbero avere qualcuno da portare in tribunale se qualcosa va storto a causa della tecnologia usata, vedi banche etc.

Almeno questo e' il mercato IT qui in UK. Aziende grandi o di vecchia mentalita' diciamo tendono a preferire (ed assumere per) .NET e Java, mentre giovani startups che hanno bisogno di sfornare prodotti velocemente e con budgets limitati, preferiscono soprattutto Rails (e FOSS in generale), seguito in minor misura da Django e altri simili.

Python non e' difficile da imparare, e' soltanto diverso, cosi' come Ruby - che comunque e' il mio preferito (lavoro piu' con Sinatra e Rails).
Trattandosi di linguaggi dinamici e dynamically typed (che NON sono la stessa cosa, come molti credono), possono condizionare in maniera significativa come le applicazioni vengono sviluppate e come funzionano, rispetto a linguaggi statici.

Un esempio e' il meta programming, che ti consente ti modificare a runtime il comportamento e la natura di un qualsiasi oggetto sia class level che instance level senza toccare l'oggetto originale se vuoi, cosa non direttamente possibile con linguaggi statici e che rende molto potente la possibilita' di fare override -o come direste in italiano- di funzionalita' di componenti e dipendenze esterne, molto, molto piu' potente che con linguaggi statici.


Come detto il mio preferito e' Ruby, che uso praticamente per tutto - dallo sviluppo vero e proprio (APIs => Sinatra, web apps => Rails) al task automation etc.

Cmq dipende anche dai requisiti in performance. A volte mi capita di fare drop di C code in Ruby per accelerare alcune cose, ma in generale Python e' molto piu' veloce, quindi lo preferirei in alcuni casi.

[cdimauro]

Soltanto una nota. Python, pur essendo dinamico e dinamicamente tipizzato, è anche fortemente tipizzato, al contrario di altri linguaggi (non necessariamente dinamici, ma anche statici) che sono debolmente tipizzati.

Per il resto, non posso che concordare.

[khelidan1980]

Originariamente inviato da Freaxxx

sento spesso parlare del confronto .net contro java, in parole povere il confronto si riduce a parlare sempre degli stessi termini:
- portabilità
- semplicità di programmazione e conseguentemente maggiore velocità di produzione
- costi di produzione di un servizio o tot servizi

adesso vorrei fare la classica domanda che spariglia tutto: perché nessuno cita mai python ?

Abbiamo ad esempio la più grande società fornitrice di servizi web, per altro gratuiti nella stragrande maggioranza dei casi, ma questo rientra nello schema più grande dell'advertising che nel mondo tecnico informatico, che usa python per la qualsiasi cosa.

è difficile da gestire python ? è difficile da imparare ?

ma figurati, se nel 2010 si varano progetti nuovi utilizzando cobol e java 1.3, dove vuoi andare...l'unica soiluzione come diceva qualcuno è lavorare per qualche start-up

[Sisupoika]

cobol....wtf???? scherzi, vero?

Originariamente inviato da Sisupoika

Se parliamo di web development direi che sia .NET che Java sono tecnologie old-fashioned che non hanno nulla a che vedere con la produttivita' di frameworks come Rails (Ruby) e Django (Python) a causa della troppa configurazione e del processo di sviluppo troppo "pesante" e lento.

Purtoppo sono ancora molto popolari soprattutto presso corporates che preferirebbero avere qualcuno da portare in tribunale se qualcosa va storto a causa della tecnologia usata, vedi banche etc.

Almeno questo e' il mercato IT qui in UK. Aziende grandi o di vecchia mentalita' diciamo tendono a preferire (ed assumere per) .NET e Java, mentre giovani startups che hanno bisogno di sfornare prodotti velocemente e con budgets limitati, preferiscono soprattutto Rails (e FOSS in generale), seguito in minor misura da Django e altri simili.

Python non e' difficile da imparare, e' soltanto diverso, cosi' come Ruby - che comunque e' il mio preferito (lavoro piu' con Sinatra e Rails).
Trattandosi di linguaggi dinamici e dynamically typed (che NON sono la stessa cosa, come molti credono), possono condizionare in maniera significativa come le applicazioni vengono sviluppate e come funzionano, rispetto a linguaggi statici.

Un esempio e' il meta programming, che ti consente ti modificare a runtime il comportamento e la natura di un qualsiasi oggetto sia class level che instance level senza toccare l'oggetto originale se vuoi, cosa non direttamente possibile con linguaggi statici e che rende molto potente la possibilita' di fare override -o come direste in italiano- di funzionalita' di componenti e dipendenze esterne, molto, molto piu' potente che con linguaggi statici.


Come detto il mio preferito e' Ruby, che uso praticamente per tutto - dallo sviluppo vero e proprio (APIs => Sinatra, web apps => Rails) al task automation etc.

Cmq dipende anche dai requisiti in performance. A volte mi capita di fare drop di C code in Ruby per accelerare alcune cose, ma in generale Python e' molto piu' veloce, quindi lo preferirei in alcuni casi.

Dio quanto ti capisco e appoggio.

Ho lavorato per anni con PHP, poi sono passato a Ruby (RoR) per "diletto" e allora ho visto LA LUCE!!!!

Adesso lavoro principalmente in Java e passare dallo sviluppo web con Rails a Spring2/3, Ibatis, Hibernate ecc. fà venire voglia di suicidarsi.

Per carità, trovo Java un fantastico linguaggio, molto potente e versatile ma se devo guardare alla semplicità e rapidità di sviluppo siamo decisamente rimasti indietro rispetto a linguaggi dinamici come Ruby/Python e relativi framework.

Con Java devi essere molto più "rigoroso" (altrimenti nemmeno compila ), il che ti evita sicuramente la creazione di bug "banali", dall'altra parte la mostruosa quantità di righe XML di configurazione non fà altro che rende tutto molto più "ERROR PRONE" e quando le scadenze si avvicinano sei costretto, a volte, a scrivere codice poco "ortodosso" per venire a capo di qualche problematica che ti ha fatto rallentare. Il tutto, ovviamente, a danno della manutenibilità.

Viva Ruby e Rails!!!!

[Sisupoika]

Java.... se rimanesse l'unica opzione aprirei un negozio di frutta
Lo !!!ODIO!!!

[Ludo237]

Originariamente inviato da Sisupoika

Java.... se rimanesse l'unica opzione aprirei un negozio di frutta
Lo !!!ODIO!!!

[dojolab]

Quanto odio
Io arrivo da PHP e qualche mese fa ho iniziato ad usare Python e DJango.

Java lo uso per 'lavoro'.

[Freaxxx]

non per sapere i fattacci vostri: ma mi date una idea di quello che si intende per applicazione aziendale, a conti fatti ?

quindi alla fine Ruby e Python pagano lo scotto di non avere una azienda grande alle spalle che li rappresenti? quindi devo desumere che di cause contro Sun, Oracle e Microsoft ce ne siano a quintalate

[tomminno]

Originariamente inviato da Sisupoika

Se parliamo di web development direi che sia .NET che Java sono tecnologie old-fashioned che non hanno nulla a che vedere con la produttivita' di frameworks come Rails (Ruby) e Django (Python) a causa della troppa configurazione e del processo di sviluppo troppo "pesante" e lento.

Già che parlate di old-fashioned mi fate capire un esempio di quanto possano essere più produttivi Rails o Django per la realizzazione di tabelle html con la visualizzazione di operazioni CRUD, ordinamento, paginazione, esportazione in pdf, excel, word, colonne riordinabili a piacere dall'utente, customizzazione di ogni elemento tramite Css.

Cosa intendete esattamente per maggiore produttività?
Perchè lavorando in un posto dove di tabelle come le summenzionate ne vengono realizzate circa 100 l'anno strumenti che possano essere molto produttivi da questo punto di vista fanno comodo.

E poi se il lavoro viene affidato all'esterno non è che se ho 10 team mi ritrovo con 10 volte il calendario o anche la tabella reimplementata in maniera diversa a seconda di come gira al team di turno e magari non tutte customizzabili allo stesso modo?

Che supporto c'è per i vari standard WS-*?
Integrazione con ESB?

Grazie per le eventuali risposte!

[eraser]

Originariamente inviato da Sisupoika

Java.... se rimanesse l'unica opzione aprirei un negozio di frutta
Lo !!!ODIO!!!

Non posso concordare di più

Originariamente inviato da tomminno

Già che parlate di old-fashioned mi fate capire un esempio di quanto possano essere più produttivi Rails o Django per la realizzazione di tabelle html con la visualizzazione di operazioni CRUD, ordinamento, paginazione, esportazione in pdf, excel, word, colonne riordinabili a piacere dall'utente, customizzazione di ogni elemento tramite Css.

Un ordine di grandezza è difficile da dare perchè dipende molto dalla conoscenza che hai dei linguaggi e dei framework utilizzati.
Comunque sia con Rails, secondo me, si può fare quanto hai citato sopra nella metà del tempo che si impiegherebbe con lo SpringFramework + Hibernate/iBatis.

Cosa intendete esattamente per maggiore produttività?
Perchè lavorando in un posto dove di tabelle come le summenzionate ne vengono realizzate circa 100 l'anno strumenti che possano essere molto produttivi da questo punto di vista fanno comodo.

Per produttività io intendo la quantità (al pari della qualità) di lavoro svolto in base al tempo e alle energie dedicate ad esso.

[Sisupoika]

Originariamente inviato da Freaxxx

non per sapere i fattacci vostri: ma mi date una idea di quello che si intende per applicazione aziendale, a conti fatti ?

Beh, rispondo per me. Nel mio caso per "applicazioni" intendo APIs di una certa dimensione e applicazioni che consumano queste APIs, il tutto facente parte di una piattaforma di advertising online, che e' il mio lavoro al momento.

Con Ruby e frameworks come Sinatra (per API) e Rails (per le applicazioni che consumano queste API), ho scritto direttamente o guidato (come head of development) lo sviluppo di una piattaforma di advertising in pochi mesi. E la API principale si occupa di data collection, data cleansing & validation, e delivery verso i clients (advertisers).

Se avessi scritto un sistema simile in Java, c'avrei/avremmo impiegato anni

quindi alla fine Ruby e Python pagano lo scotto di non avere una azienda grande alle spalle che li rappresenti? quindi devo desumere che di cause contro Sun, Oracle e Microsoft ce ne siano a quintalate

Un po' si', anche se come detto la mentalita' in proposito sta cambiando eccome, visti gli indubbi vantaggi.

Prova a cercare su http://www.cwjobs.co.uk/ per Ruby jobs, per esempio.

Originariamente inviato da tomminno

Già che parlate di old-fashioned mi fate capire un esempio di quanto possano essere più produttivi Rails o Django per la realizzazione di tabelle html con la visualizzazione di operazioni CRUD, ordinamento, paginazione, esportazione in pdf, excel, word, colonne riordinabili a piacere dall'utente, customizzazione di ogni elemento tramite Css.

Cosa intendete esattamente per maggiore produttività?
Perchè lavorando in un posto dove di tabelle come le summenzionate ne vengono realizzate circa 100 l'anno strumenti che possano essere molto produttivi da questo punto di vista fanno comodo.

E poi se il lavoro viene affidato all'esterno non è che se ho 10 team mi ritrovo con 10 volte il calendario o anche la tabella reimplementata in maniera diversa a seconda di come gira al team di turno e magari non tutte customizzabili allo stesso modo?

Che supporto c'è per i vari standard WS-*?
Integrazione con ESB?

Grazie per le eventuali risposte!

Per produttivita' intendevo: velocita' di realizzazione di applicazioni che siano performanti, sicure, scalabili e che si possano agevolmente e rapidamente aggiornare, ristrutturare, etc.

Non per riproporre roba cotta e ricotta quando si parla di Rails e simili, cmq i vantaggi principali sono -soprattutto per Rails:

- una implementazione pressocche' perfetta di MVC (addirittura la parte dei controllers in Rails e' rimasta piu' o meno la stessa in anni perche' era gia' stata "indovinata")

- configurazioni ridotte ad un minimo, e sostuite invece da una marea di convenzioni. Il framework propone tutta una serie di practices (nella maggioranza dei casi best practices): se semplicemente ti attieni ad esse, puoi pensare di meno ad una marea di cose e concentrarti di piu' su cio' che la tua applicazione deve fare, e come ottenerlo

- database migrations molto user friendly, e un ORM che funziona come si deve (anche se non perfetto - naturalmente parlo di ActiveRecord, visto che e' il piu' usato)

- tutta una serie di vantaggi che derivano, come gia' citato, dal fatto di usare per esempio Ruby invece che C# o Java ( :asd )

Originariamente inviato da Sgurbat

Un ordine di grandezza è difficile da dare perchè dipende molto dalla conoscenza che hai dei linguaggi e dei framework utilizzati.
Comunque sia con Rails, secondo me, si può fare quanto hai citato sopra nella metà del tempo che si impiegherebbe con lo SpringFramework + Hibernate/iBatis.

Giusto per essere carini?

Per produttività io intendo la quantità (al pari della qualità) di lavoro svolto in base al tempo e alle energie dedicate ad esso.

Uhm... la tua definizione e' 1000 volte meglio della mia

[tomminno]

Originariamente inviato da Sgurbat

Un ordine di grandezza è difficile da dare perchè dipende molto dalla conoscenza che hai dei linguaggi e dei framework utilizzati.
Comunque sia con Rails, secondo me, si può fare quanto hai citato sopra nella metà del tempo che si impiegherebbe con lo SpringFramework + Hibernate/iBatis.

Di Java per il web ho una limitata (e molto pessima) esperienza, utilizzo prevalentemente webservice e Mule Esb. Il mio riferimento di produttività web è .Net (Asp.Net) dove posso fare tutta l'interfaccia semplicemente selezionando quello che voglio ottenere da Visual Studio, senza scrivere una riga di codice, dove le tabelle recuperano automaticamente i campi dalla sorgente dati impostata e altrettanto automaticamente mi impostano il corretto formato di editing (date con calendari, booleani con checkbox, ecc), i css si impostano da editor grafici con preview automatica del risultato, che poi il grafico ottimizzerà per proprio conto, senza interferire con il lavoro del programmatore.

Ho già provato e scartato Asp.Net Mvc in quanto sebbene nettamente superiore come organizzazione logica delle richieste, comporta una non proporzionale maggiore "perdita di tempo" sui dettagli dell'interfaccia che non lo rende conveniente rispetto ad Asp.Net classico.
Per non parlare del fatto che i grafici devono mettersi lì a mischiare C# e html.

Non c'è la netta separazione tra i compiti del programmatore e quella del grafico in nessuno dei tool che ho mai sperimentato in quanto entrambe le figure devono intervenire sugli stessi file, Asp.Net per lo meno tiene ben separata la parte grafica dalla logica dell'applicazione, una volta che il programmatore ha stabilito cosa visualizzare il grafico si limita a ritoccare senza intervenire nella generazione dell'html.
In questo contesto ad oggi mi sembra che il più vicino all'ideale separazione dei compiti sia, strano a dirsi, Qt con QML, a confronto XAML perde per il fatto che è una sintassi estranea per qualcuno che abitualmente lavora con Css, Javascript e Flash.

Per produttività io intendo la quantità (al pari della qualità) di lavoro svolto in base al tempo e alle energie dedicate ad esso.

Si mi riferivo nel concreto riguardo al contesto web, volevo capire in cosa si è più produttivi.

[tomminno]

Originariamente inviato da Sisupoika

- una implementazione pressocche' perfetta di MVC (addirittura la parte dei controllers in Rails e' rimasta piu' o meno la stessa in anni perche' era gia' stata "indovinata")

Ma nella View c'è un misto di codice Ruby che genera html? Dagli esempi che ho visto in rete mi pare sia così. Se si come ti trovi quando devono intervenire i grafici? Perchè grafici e codice è un'accoppiata fallimentare, secondo la mia esperienza.
Quanto tempo impieghi per generare una View con tutti i ninnoli grafici che le scimmie utilizzatrici tanto amano?
Ogni volta c'è da riscrivere sempre le solite cose?

- configurazioni ridotte ad un minimo, e sostuite invece da una marea di convenzioni. Il framework propone tutta una serie di practices (nella maggioranza dei casi best practices): se semplicemente ti attieni ad esse, puoi pensare di meno ad una marea di cose e concentrarti di piu' su cio' che la tua applicazione deve fare, e come ottenerlo

Puoi dettagliare meglio?
A cosa non devi pensare sviluppando in Ruby?

- database migrations molto user friendly, e un ORM che funziona come si deve (anche se non perfetto - naturalmente parlo di ActiveRecord, visto che e' il piu' usato)

Sinceramente è molto difficile che un applicativo web cambi il dbms utilizzato, vuoi perchè generalmente tendi ad utilizzare comunque le peculiarità di un DBMS (già che lo usi) e che la migrazione della base dati non è che sia poi così trasparente.

- tutta una serie di vantaggi che derivano, come gia' citato, dal fatto di usare per esempio Ruby invece che C# o Java ( :asd )

Ovvero? Messa così senza una spiegazione più dettagliata di quali possano essere i vantaggi, fa un pò spot.

[Sisupoika]

Originariamente inviato da tomminno

... Il mio riferimento di produttività web è .Net (Asp.Net)

LOL, davvero non posso fare a meno di sorridere

dove posso fare tutta l'interfaccia semplicemente selezionando quello che voglio ottenere da Visual Studio, senza scrivere una riga di codice, dove le tabelle recuperano automaticamente i campi dalla sorgente dati impostata e altrettanto automaticamente mi impostano il corretto formato di editing (date con calendari, booleani con checkbox, ecc), i css si impostano da editor grafici con preview automatica del risultato, che poi il grafico ottimizzerà per proprio conto, senza interferire con il lavoro del programmatore.

Forse non te ne rendi conto (probabilmente perche' non hai ancora provato alternative come quelle gia' suggerite), ma hai appena descritto i piu' grossi limiti di .NET e del principale tool, Visual Studio.

Il significato di queste parole diverra' piu' chiaro quando incominci a lavorare, per esempio, con Rails. E te lo dice uno che ha 8 anni di sviluppo .NET (AVANZATO - mi basti dire che ho scritto booking engines e/o backends per aziende come Last Minute, Expedia, Travelocity, Eurostar, Easyjet, etc - quando ancora lavoravo nella travel industry e principalmente in .NET prima di spostarmi nell'advertising e lavorare con Ruby a tempo pieno da qualche anno)

Ho già provato e scartato Asp.Net Mvc in quanto sebbene nettamente superiore come organizzazione logica delle richieste, comporta una non proporzionale maggiore "perdita di tempo" sui dettagli dell'interfaccia che non lo rende conveniente rispetto ad Asp.Net classico.

Ooops... da quanto ho letto prima speravo che ALMENO tu lavorassi in MVC
Lavori ancora con quell'obbrobrio dei web forms? Non ho mai fatto esperienza con orrore piu' grande da quando lavoro nel web.
Se parli di perdita di tempo vuol dire che non vi hai neanche lavorato. MVC, nella sua implementazione in .NET, mi fa pena in confronto a Rails, Django e altri, ma almeno e' anni luce meglio di quei orribili web forms.

Chi lavora ancora oggi con web forms e roba simile, tanto per cominciare non ha molto a cuore le prestazioni sia server side che client side di una applicazione

Non te la prendere: piu' che come critica, leggi i miei commenti come un invito a provare qualcosa di meglio, da parte di uno che ha una certa esperienza con varie tecnologie e piattaforme (lavoro nel settore da 15 anni, e da 10+ con esperienze miste tra vari frameworks - tra cui appunto .NET, Rails etc, vari DBRMS, e vari OS -tra cui ovviamente Linux, e Mac OS assieme a Windows).

Alla fine poi, e' anche vero che il toolset perfetto per ognuno e' quello che piace e in cui ci si riconosce.

Per non parlare del fatto che i grafici devono mettersi lì a mischiare C# e html.

La strada provata coi webforms e' stata imho un totale fallimento. Non solo Microsoft. Mai sentito parlare di http://www.visualwebgui.com/ ?
Lo e' stato -sempre imho- sin dalla concezione come idea, dal momento che non si puo' equiparare (e pertanto lavorarci sopra) il web -che e' stateless e dipendente da varie constrinzioni- ad un sistema desktop.

Parli di mischiare codice con design? Giusto. Per questo esiste MVC, e nelle implementazioni piu' corrette -come Rails- se usato e "rispettato" come si deve, non vedrai mai uno "spaghetti code" degno di questa label, e in cambio avrai migliori performance e ineguagliabile flessibilita'.

Se lavori in MVC (qualunque implementazione), ti basta seguire queste semplici regole:

- MAI eseguire queries (con un ORM o altrimenti), in un controller. MAI! Qualunque funzionalita' che ha a che fare con il contenuto o comportamento di un model, VA NEL MODEL e va esposto come metodo accessibile, o come per esempio named scope

- MAI HTML in un controller o, peggio, ritornato da un metodo da un model. Le views esistono per questo.

- MAI eseguire query o comunque business logic nelle views, che vada oltre il print di un valore o looping through a collection. Se proprio necessario, ci sono gli helpers.

Se segui queste regole con un framework MVC, hai applicazioni molto -enormemente- piu' flessibili e performanti che con webforms, e una struttura ordinata, familiare, con una perfetta separation of concerns.

Non c'è la netta separazione tra i compiti del programmatore e quella del grafico in nessuno dei tool che ho mai sperimentato in quanto entrambe le figure devono intervenire sugli stessi file, Asp.Net per lo meno tiene ben separata la parte grafica dalla logica dell'applicazione, una volta che il programmatore ha stabilito cosa visualizzare il grafico si limita a ritoccare senza intervenire nella generazione dell'html.

Dipende, con qualunque framework (persino webforms) puoi lavorare con temi, anche in modo tale che i designers possano lavorare su templates senza dover mischiare del codice. Il tutto dipende dal come le applicazioni vengono sviluppate.