Asp.net - fördelar / nackdelar
 

Hej!

Sitter just nu och utvecklar i vb.net (asp.net) och i takt med de problem som uppstår så stiger frustrationen exponentiellt. Det vore trevligt att få höra era åsikter som verktyget.

Åsikter från folk utan erfarenhet av vb.net / asp.net undanbes :)

Själv ser jag följande problem:

* Event. Eventen kommer ibland i ologisk ordning i kombination med att dokumentationen på området är rätt kass.

* Kontrollers instanser. Ibland är det när omöjligt att få tag på olika kontrollers instanser. FindControl är otillräcklig. Att säga att "det är dåligt pattern" att behöva känns till olika kontrollers instanser är att göra det jävligt lätt för sig.

* Datagrid. En mastodont-kontroll som personifierar allt som är dåligt med asp.net. Håll dig till ramarna = Det går OK, gå utanför ramarna = Du får ett helvete. Och tyvärr är det inte sällan man måste gå utanför ramarna.

* Webkontroller. Ibland kan det vara helt omöjligt att få koden att validera eller utföra det man vill göra. Får en känsla av att asp.net skriver xhtml lika bra som ie6 tolkar den.

* ViewState. Onödigt-jävla-bloat.

* VisualStudio 2008. Grattis Microsoft, er IDE är till och med segare än eclipse. Förutom det så förutsätter editorn att man har en kognitivt nedsatt funktionalitet och inte själv vet hur man vill att koden skall se ut.


Och jag gillar följande:

* Ehh.. Jo.. alltså.. vi har ju det här med... ehm..

Event:
Ologiskt, hmm, kanske. Finns dokumenterat, krävs lite grävande. Själv använder jag mest OnPreInit och Page_Load.

Kontrollers instanser:
Om du behöver FindControl kanske du har tänkt "fel"?

DataGrid:
Använd GridView eller Repeater.

Webkontroller:
Säger inte emot valideringen

ViewState:
Håller med

VS2008:
Byt till VS2010

Själv kör jag numera en hybrid av asp.net webapp och mvc. Minskar bloatet och ökar kontrollen över applikationen. Har också stoppat undan mkt av repetitivt kodande i ett bibliotek.

(Och så kör jag C#, men det är mer tycke och smak där...)

Förstår att du antagligen var hyfsat irriterad när inlägget skrevs, hoppas att det är muntrare toner nu. Jag har suttit med klassisk ASP (VBScript - ugh!) hela dagen - vill du byta? Nä, tänkte väl det. ;)

Jag ogillar eventen också men det underlättar ju mer man kodar. Är webforms relativt nytt för en kommer man åka på en massa strul. Ibland har jag till exempel fortfarande problem med vissa kombinationer av events trots ca 2 års webformskodande.
Det jag tycker är dåligt med webformsdesignen är att det ökar risken för runtime exceptions. Gör man fel sak i fel event eller missade att det borde ha skett i ett annat event, då får man bara hoppas att man testat sin kod ordentligt. Dessutom blir koden utspridd när vissa delar körs i eventen x, y och z. Kanske beror det på att jag suttit med Java och MVC-ramverk tidigare men det känns bara så himla onödigt med den här typen av problem.

Är inte med på vad du menar. Kan du ge ett exempel?


Ja, men det finns inget som hindrar dig från att skriva egna controls eller overrida de som redan finns. Dom inbyggda funkar i många lägen men det betyder inte att de funkar i alla. Om du tänker dig dem som grundläggande men ganska funktionella controls blir det lite mindre frustrerande. :)

Min åsikt är den att man får ta webforms för vad det är (eller verkar vara): ett ramverk för att utveckla snabbt utan att kunna särskilt mycket om webben. Outputten verkade inte vara viktig när MS kom på webforms. Det ska ha blivit bättre i v4 men det är bara vad jag hört. Jag är inte så intresserad av att ta reda på om det stämmer eller ej utan är desto mer sugen att hoppa på Asp.net MVC till 100% istället. Du kanske borde göra likadant om möjligheten finns.

Webforms är för windows/desktoputvecklare som inte kan, vill eller orkar lära sig webbutveckling. Det är min syn på ramverket. Jag gillar det inte speciellt mycket men tyvärr är det just webforms vi kör med på jobbet pga att plattformar inte finns för MVC än. I många fall är det åtminstone på g så man får väl hålla ut ett tag till.

Om du tycker att det är onödigt är det bara att slå av det i web.config.
Men återigen: viewstate är ännu en grej som MS la in för att underlätta för (desktop)utvecklare. Det i sin tur leder lätt till prestandaproblem iom gigantiska viewstates. Tror dom flesta som har jobbat med webforms ett tag har sett sådana någon gång. Annars är det dags att kolla i källkoden. ;)

Om du inte har testat VS 2010 är det ett hett tips. Den är bättre än 2008 och framförallt mycket snabbare. Eclipse har länge varit min favorit men nu vet jag inte längre.

Nja. Jag kan bara hålla med om att det är lite så och så med valideringen mot xhtml, annars är det du talar om otroligt kraftfullt om det används på rätt sätt. Hur längre har du kodat i .net? Kanske är det en vanesak?

Har hört mycket gott om Microsofts MVC. Hoppas att jag får chans att pröva det nån gång :-)

Haha jag var inte nådigt trött på det hela. Nu är jag tillbaka i mitt lugna jag igen. Lider riktigt mycket med dig - klassisk ASP har också sina brister. Mins framförallt att libbet var så litet att man var tvungen att köpa till massa moduler, moduler som inte sedan fungerar när man kör på nyare Windows-versioner, etc. *ryser*

I .net har jag kodat i flera år, men asp.net är nytt sedan ett halvår tillbaka. Har utvecklat i de flesta miljöer man kan tänka sig, både desktop och web - och är helt tagen av hur dåligt jag upplever asp.net. Kan dock tillägga där att applikationen i fråga är mycket gammal och inte speciellt välskriven från början. Det är svårt att bygga korthus om grunden är dålig :-/

Är säker på att man, som ni nämner, kan skriva asp.net på ett bra sätt. Speciellt om man har moderna verktyg och versioner. Men då och då stöter man på situationer där man tänker "hur f*n tänkte Microsoft här" :-P

Men om vi snackar fördelar med ASP.NET jämfört med andra ramverk, skulle ni säga att det främst är den påstått korta utvecklingstiden för mindre projekt som är fördelen? Finns det fler fördelar?

Den stora fördelen skulle jag vilja säga är att det är lätt att integrera olika interna Microsoft-baserade system. Har man ett hyfsat funktions- och klassbibliotek så blir utvecklingstiden ofta ganska kort även för vanlig PHP. Jag har själv jobbat en hel del med både gammal klassisk ASP och .NET / C# tidigare men är ärligt talat inte särskilt förtjust i det. Gillar att ha mer kontroll över koden.

Jag har arbetat med .NET ända sedan det kom, och samtidigt med PHP och ser både för och nackdelar med båda sidorna..

Fördelar med .NET:
* Smidig utvecklingsmiljö ( visual studio )

Nackdelar med .NET:
* Genererar otroligt ful kod ( om man inte anpassar med t.ex MVC ).
* Dålig prestanda ( av många anledingar, bland annat pga den fula koden som generaras ).
* buggar ofta vid hög belastning. ( IIS:en klarar t.ex inte av att processen tar mer än 4 gb ).
* Utvecklingsverktyget visual studio och en webbserver med IIS kostar ganska mycket pengar.



Kort och gott, jag ser faktiskt ingen framtid i .NET. Anledningen till att företag fortfarande använder .NET är för att det är såpass integrerat med Microsofts övriga produkter och att det är ett smidigt utvecklingsverktyg.

Prestanda kan man inte säga är dålig med ASP.NET, då det är kompilerad kod jämfört med t.ex PHP.
Inte heller kan man generalisera och säga att den buggar vid hög belastning. Det är ofta felaktig konfiguration eller dyligt som orsakar prestandabuggar inte tekniken i sig.

Jag har tidigare jobbat med en relativt stor site och sett utmaningarna vid extrem belastning, Jag syftar väll inte direkt på ASP-Net i sig utan mer en kombination av IIS:en, windows server och ASP.NET. Ett exempel är t.ex att processen för asp.net / ISS inte får använda mer än 4 GB minne, använder den mer så hänger hela IIS sig..vet inte om dem fixat dessa buggarna ännu men det är sådana saker som får en att tröttna..

Sant, jag tror den generella uppfattningen är att ASP.NET är snabbare än PHP vid låg belastning, men att PHP skalar bättre vid högre belastningar. Det gäller dock rätt skriven ASP.NET, eftersom vissa funktioner är extremt dyra ur ett prestandaperspektiv. Detta gäller även till viss del PHP även om det inte tycks vara lika farligt - man måste dock alltid känna sin kod och prestandatesta / profilera mycket, oavsett miljö.

En grej med ASP.NET som jag finner oerhört störande är alla ständiga omkompileringar man måste göra. Otroligt mycket utvecklingstid går åt att stoppa, kompilera om, starta och sedan hamna i rätt state (logga in + gå till rätt sida på din sajt). Finns det något sätt man kan komma ifrån / snabba upp detta?

Frågan är väl om ska jämföra ASP.NET med PHP rakt av.
Det mest rättvisa är väl att jämföra standard ASP.NET med PHP och ett "framework" t.ex Zend och kanske en opcode cache installerad.
Dock känns diskussionen kanske aningen onödig då man bevisligen kan bygga skalbara tjänster i bägge tekniker.

Håller med, den största anledningen till att jag väljer PHP till egna projekt.
Det går väl lite snabbare att köra on-the-fly kompilering (eller vad det kallas) dvs använda CodeFile istället för Codebehind. Men det har andra nackdelar.

My point exactly. En duktig utvecklare behöver kunna flera olika miljöer för att kunna välja rätt teknik till projektet och inte tvärt om.

Jag skall erkänna att jag inte hade en aning om att CodeFile fanns, och det verkar onekligen smidigare. Dock så tror jag att jag får hålla mig till CodeBehind i detta befintliga projekt för att det inte skall bli mer spretigt. Tack för hjälpen!

Litet sidospår:

Är det verkligen utvecklaren som väljer teknik, trodde det var en arkitekt eller motsvarande? Eller är det jag som jobbat i för stora projekt på sistone?

Du är också konsult förstår jag ;-)

Oh yes, I am :)

Såg nu att det finns en App_Code folder där man placera kod filer som kompileras automagiskt
http://msdn.microsoft.com/en-us/library/t990ks23.aspx
Vet inte om det kan användas utan att ange CodeBehind eller CodeFile dock(?)

Jodå, det är ett alternativ att samla vanliga funktioner på ett och samma ställe. Bekvämt och enkelt på kort sikt och krångligt och oöversiktligt på lång sikt.

Visst kan det tyckas vara smidigt att ändra direkt på servern men förr eller senare gör någon (läs. någon annan än jag;)) något på servern som inte finns versionshanterat. Dessutom kan man argumentera för om man verkligen ska pilla på filer på servern för hand öht. Genom byggservrar kan man ju få till sånt där på ett jäkla fiffigt sätt där bl.a. unit- och UI-tester körs först. Sen, om alla testerna var ok, då skickas den kompilerade koden ut till servern. Det här borde vara drömmen för alla som utvecklar. Manuellt arbete är ju en stor PITA.

Om man vill kan man ladda upp källkoden - aspx och codebehind - men jag har svårt att se något bra med att göra det. När man använder CodeFile kör man på WebSite-projekttypen och det är väl en smaksak om man föredrar den varianten eller WebApplication. Det är inte helt lätt att läsa sig till vad som passar en bäst så det bästa är att sätta upp en litet testprojekt och testa sig fram.

App_Code är för WebSite-projekt. Kör ni med WebApplication är det App_LocalResources som gäller.

Lägger du kodfiler i App_LocalResources? Där ska väl bara resursfiler ligga såsom resx etc? I min värld lägger man inga kodfiler öht i webbprojektet, utan man lägger businesslagret i ett eget projekt (class library) och DAL i ett eget projekt. Fördelen blir ju också att man minskar kompileringstiden om man har flera projekt då den inte behöver kompilera allt varenda gång. Jag förespråkar även web application project framför web sites, det är mer ordning och reda i wap :)

Däremot precis som TS säger så lägger man ju overkligt mycket dötid på att komma till sidan man jobbar med, dvs loggar in, klickar här o där för att hitta till rätt ställe. Om nån har nåt tips hur man minskar den tiden vore jag tacksam. Sen är diskussionen i sig för mig intressant, då jag enbart jobbat med .net sen 2002, så kul att få lite input vad folk tycker är bra resp dåligt. Man blir ju lite hemmablind om man säger som så :)

Ibland är det inte nödvändigt att skapa separata projekt och då är det appcode/localresources som gäller. Jag menade inte att det är bra att lägga klasser där men för mindre projekt är det mer okej om du förstår vad jag menar.

Selenium har tillägg för vissa webbläsare (Firefox och Chrome har jag för mig) där man kan spela in musklick, textfältsändringar och liknande. Sedan kan man spela upp händelsena när man känner för det. GUI:t är inte direkt intuitivt men det finns bra intros på nätet.

Att jämföra Asp.Net med PHP eller Ruby för den delen är lite som att jämföra äpplen med päron och apelsiner ;O)

Har själv nyligen gått över till Asp.Net MVC och kan säga att en helt ny värld har öppnats för mig. Jag kan skriva renare applikationer, få till tydliga separationer mellan kod och design och allting blir väldigt "testbart".

Hett tips är att du plöjer igenom Nerddinner (googla på det) för att komma in i MVC tänket, som skiljer sig en hel del från Webforms.

Kan även tipsa om ett riktigt grymt CMS som nyligen(12 jan) släpptes, Orchard (Ja , Microsoft har börjat flirta med open source communityn =) )

Spana in den på orchard.codeplex.com , enkel att installera, (ja faktist enklare än Wordpress), däremot att börja utveckla med den är lite mer trögstartat men det ganska mycket dokumentation.

Att det skulle vara dyrt att driva och uteveckla asp.net siter köper jag inte, Visual web developer är gratis, hos tex Axentus kan du drifta IIS + MS SQL server för 900kr om året och har du en process som äter upp 4gb ram så har du gjort något fel :)

Såg en demo av MVC, uppfattade det så att man inte längre använder webbkontroller tex DropDownList, TextBox m.m . och ingen ViewState. Stämmer det?

Beror väl lite på projektets storlek, I större projekt i miljonklassen har man kanske en arkitekt, men i mindre projekt får utvecklaren vara arkitekten.

Stämmer bra det.
man har "tagit ett steg bakåt" och kodar vyerna med liknande syntax som gamla ASP 3.0. På så sätt får man full kontroll på html-koden (igen).

Den enda C#/VB kod som ligger i vyerna är den som hanterar hur modellen som skickas in skall skrivas ut, tex for-loopar och if-satser.

Microsoft har väll insätt att koden som dem genererar är crap..

MVC är absolut ett steg i rätt riktning och att dom sopat Viewstate är nog det bästa val dem gjort på länge!

Personligen gillar jag inte if-satser i vyerna, kör efter regeln , om det behövs en if-sats, skriv en HTML-helper.

Det där med att droppa in kontroller som fungerar "out of the box" med en datasource går ju att återskapa i MVC , även den med hjälp av återanvändningsbara HTML-helpermetoder.