Diskussion:ASP.NET

aus Wikipedia, der freien Enzyklopädie

Welches Substantiv passt zu subsequent? Adjektive sollte ja möglichst nicht als Lemma verwendet werden, also ist der Wiki-Link so unsinnig. --ChristianErtl 15:41, 30. Sep 2005 (CEST)

Inhaltsverzeichnis 1 Artikel überarbeiten 2 Coolness-Faktor? 3 MS Bashing 4 Vor- und Nachteile 5 Nachteile 6 Weiteres Vorgehen

[Bearbeiten] Artikel überarbeiten

Der Link auf ASPX führt wieder zu dieser Seite.
Gibt es da Unterschiede oder nicht?
Kann da jemand mit Kompetenz was zu schreiben?
Wenn es keine eigene Seite für ASPX gibt, würde ich den Link rausnehmen.

--Johannes 01:12, 5. Aug 2005 (CEST)

Auch mit erledigt wenn ich schon mal am Umstrukturieren bin...

Es fehlt ein Beispiel, was ich damit jetzt konkret machen kann... Ein Forum? Einen Freemailer? Oder noch mehr? Wo sind die Grenzen? : :So, denke, das war erst mal ein Anfang, mal schauen was wir noch so an Informationen in den Artikel reinkriegen ;)

--E7 22:18, 10. Jul 2006 (CEST) --E7 23:23, 10. Jul 2006 (CEST) --E7 23:15, 13. Jul 2006 (CEST)

[Bearbeiten] Coolness-Faktor?

"sowie der Coolness-Faktor von Scriptsprachen wie PHP" - Was soll damit ausgedrückt werden, und passt dieser Ausdruck hier?

[Bearbeiten] MS Bashing

Sehr viele Nachteile und nur wenige Vorteile...

Vielleicht ist ASP.NET halt nicht so toll? MS-Bashing kann ich bei bestem Willen nicht erkennen, die aufgeführten Nachteile sind allesamt nachvollziehbar und die Vorteile kommen auch nicht zu kurz. Btw: Mit --~~~~ kannst du deine Beiträge signieren. --Uellue 12:21, 28. Jul 2006 (CEST)

MS-Bashing? Wenn mal dem Artikel unterstellen will, er sei nicht neutral, dann eher, dass er zu MS-freundlich ist, nicht anders herum. Wer sich den Artikel durchliest, muss ja denken dass ASP.NET für größere Projekte das Non-Plus-Ultra ist... Bin dafür, etwas mehr OpenSource-Alternativen reinzubringen und den bescheuerten roten Kasten zu entfernen. --E7 13:47, 28. Jul 2006 (CEST)

Für mich sieht das schon nach MS-Bashing aus. Zunächst der psychologische Effekt: die Nachteile umfassen 8x (!) so viel Raum wie die Vorteile. Das sieht schonmal nach POV aus. Der Vorteil (ASP.NET ist schwierig) wurde sehr kompakt dargestellt und die Nachteile lang und breit ausgeführt. Nachteil 1 umfasst das Argument weniger Code und schweift dann ab zum Vergleich zur Vorgängerversion, Mängel in der Entwicklungsumgebung und dem objektorientierten Paradigma (noch allgemeiner gehts glücklicherweise nicht). Ich beziehe mich mal auf die einzelnen Absätze der Nachteile (ich will hier wirklich keine Lanze für MS brechen, aber ich kenne mich berufsbedingt ziemlich gut mit ASP.NET aus):

1. Code-Behind ist ein Vorteil (gilt für Trennungen allgemein, vgl. HTML und CSS). Weniger Code ebenso (ohne Diskussion). Der Programmcode kann an jeder Stelle bearbeitet werden, sowohl durch Mausgeschubse als auch auf Ebene des Quelltexts. Die Code-Behind Klasse ist keinesfalls temporär oder ein Cache-Objekt. Der Schreiber hat offenbar Probleme mit der Bedienung von Visual Studio. MS-typisch können die Klickpfade sehr lang werden. Das ist aber kein Problem von ASP.NET, denn das kann man auch mit Notepad/ vi programmieren. Absatz Löschen
2. Projektmappen sind ein Feature der Entwicklungsumgebung und gehören ggf. zur Kritik von Visual Studio. Ich habe sowohl mit als auch ohne gearbeitet und verstehe den Punkt somit überhaupt nicht. Das mit den Dateiendungen stimmt soweit. Wenn eine Datei nicht *.aspx heißt, fasst Sie der Parser auch nicht an. Das kann man durch eine Konfiguration aber umbiegen. Kürzen
3. Das Geblubber um den Patch, bezieht sich doch wohl nur auf Visual Studio und die bereits angeführten Mängel. Für das .NET Framework (beinhaltet ASP.NET) wurden keine Änderungen vorgenommen. Also auch hier völlig OT. Löschen
4. Passt, man könnte hinzufügen, dass die Verschlüsselung des Viewstates (was ist das?) nur rudimentär ist. Zumindest das Dekodieren ist sehr einfach, das Zurücksenden manipulierter Daten aber wegen serverseitiger Prüfsummen schwierig. Ausbauen
5. Was bitte ist eine normale Privatperson? Findet man die im Brockhaus? Nach dieser Argumentation ist auch PHP ungeeignet, weil es zu viele Bibliotheken gibt (für XML, Grafiken, MySql etc). Das mit dem Webspace ist ein Argument. Kürzen

Ich stelle das erstmal zur Diskussion, weil auf MS-Themen immer sehr sensibel reagiert wird. Man sollte aber aufhören Vor- und Nachteile wild zu mischen und das Negative mit Halbwissen aufzublähen. Insgesamt finde ich den Artikel ziemlich misslungen und für Interessierte komplett unverständlich. Die allgemeine Erklärung beschränkt sich auf die Aufzählung der Unterschiede zu ASP, also spezifisches Hintergrundwissen. PHP erklärt man dem Laien auch nicht, indem man es von Perl-Scripts abgrenzt. Hier wäre eine Erläuterung des Entwicklungszyklus (was muss ich machen) und Verarbeitungsmodells (was macht der Server) eher angebracht. Bei PHP hats doch auch so geklappt. -- Christoph 84.191.199.10 14:27, 23. Dez. 2006 (CET)

[Bearbeiten] Vor- und Nachteile

Ich hab mir mal die Freiheit rausgenommen Vor- und Nachteile in der Reinfolge zu drehen.

Ich gebe zu bedenken, ob ASP.NET wirkliche eine Skriptsprache ist. ("anderen Skriptsprachen")

[Bearbeiten] Nachteile

Offensichtlich ist Christoph ein bisschen überheblich: Erstens kann man ASP.NET und seine Architektur schlecht ohne das dazugehörige Visual Studio betrachten. Sicherlich könnte man eine ASP-Anwendung auch mit Notepad und den dazugehörigen Kommandozeilen erstellen. Und wahrscheinlich ist Eclipse ein wenig komfortabler. Auch gibt das .NET-Framework mehr her, als mit Visual Studio machbar ist. Aber die jeweilige Architektur von ASP.NET wurde von Microsoft nun mal vor allem über das zugehörige Entwicklungswerkzeug vorgegeben. Microsoft hat immer Visual Studio und das dazugehörige Framework als eine Einheit betrachtet.

Auch hat Christoph den Code-Behind-Mechanismus von ASP.NET 2.0 nicht durchschaut.

Ein kleines Zitat aus einer Seite von Microsoft über die Vorzüge von ASP.NET 2.0 soll hier weiterhelfen:

"Die sich ... ergebende CodeBehind-Datei ist weitaus kürzer und enthält keinen automatisch generierten Code. Die ASP.NET-Laufzeitumgebung verbindet automatisch die Ereignisse in der CodeBehind-Datei mit den Steuerelementen auf der ASPX-Seite. Das heißt, die ASP.NET-Laufzeitumgebung führt nun automatisch die Codegenerierung aus, die bisher von Visual Studio übernommen wurde." [1]

Und noch was: Der Hinweis zum Patch ist wichtig, da es nicht wenige Entwickler gibt, die bisher nicht in der Lage waren, ohne größere Umprogrammierungen ihre .NET 1.1-Anwendung auf .NET 2.0 zu migrieren. Die Alternative mit Notepad weiter zu entwickeln, kann man nicht im Ernst erwägen. Es stimmt eben nicht, dass ASP.NET, wie Microsoft auf der oben genannten Seite behauptet, vollständig abwärts kompatibel ist. Interessanterweise kam der Patch selbst aus dem Microsoft-Umfeld und wurde später von Microsoft in SP1 integriert. Microsoft hat sich wohl im Bedarf der Programmierer verschätzt, wenn seine Entwickler davon ausgingen, dass ein mehr an Automation und Klicki-Bunti auch gleichzeitig zu einer verbesserten Architektur der mit diesen Werkzeugen entwickelten Anwendungen führt. Das Problem an diesem Konzept ist, dass dem Programmierer immer mehr Entscheidungsfreiheit genommen wird und er auf die beschränkte Welt der von Microsoft bereitgestellten Tools zurückgeworfen wird oder eben doch auf Notepad. --Sesalo 23:16, 17. Jan. 2007 (CET)

Den Diskussionsbeitrag zur offensichtlichen Überheblichkeit kommentiere ich nicht. Wie du richtig erkannt hast (verzeih mir die zweite Person in der Anrede), plädiere ich dafür, ASP.NET und Visual Studio zu trennen. Eine Technologie definiert sich meiner Meinung nach nicht durch eine IDE. Das gilt für Windows Forms (C. Petzold hat 1000 Seiten geschrieben, wie man die ohne VS.NET programmiert), Java Swing (gehört nicht zu Eclipse) und eben auch für ASP.NET.

Zweifellos ist es eine Taktik von MS, Abhängikeiten durch Tools zu schaffen. Deine Antwort zeugt vom Erfolg dieses Vorhabens. Trotzdem ist ASP.NET nicht existentiell an VS gebunden, ich selbst habe mit WebMatrix [2] angefangen. Auch Code-Behind ist kein Zwang. [3] setzt nach eigenen Angaben ausschließlich auf Inline Code (alle Handler in einem definierten Scriptbereich innerhalb der aspx-Seite). Solution-Dateien und Patches für VS interessieren mich da überhaupt nicht, sondern eher wie eine solche Datei minimal wohl aussieht. Und ja, ich habe auch schon Projekte für "richtige Männer" bearbeitet.

Wir sind uns aber einig, dass Code-Behind ein Vorteil ist. Zum Nachteil wird das laut Artikel dadurch, dass dieser Code dann nicht bearbeitet werden kann. Das ist falsch: Ich kann die cs bzw. vb Datei jederzeit bearbeiten. Wie partielle Klassen zu vollständigen aufgelöst werden, hat mit der IDE überhaupt nichts zu tun. Trotzdem danke für das Nachhilfezitat, das besagt, dass die Codegenerierung nicht von VS abhängt sondern ein Plattformdienst ist. Deswegen brauche ich als "Notepader/ Dreamweaverer/ MonoDeveloper" auch keine Kommandozeile und kopiere die Quell-Dateien einfach so auf den Webspace.

Die Diskussion zeigt auf jeden Fall, dass in Sachen Exaktheit bei diesem Artikel einiges im Argen liegt (egal wer von uns jetzt blöd oder überheblich ist). Auf die Schnelle sehe ich zwei Möglichkeiten: Wir schreiben in die Einleitung, dass man ASP.NET ausschließlich mit Visual Studio (Express) entwickeln kann - dann geht auch das Blabla über Patches zu VS in Ordnung, weil ASP Bestandteil von VS ist. Oder wir stellen ASP.NET als eine von vielen Technologien für Webseiten vor, für die man verschiedene Editoren benutzen kann (wobei MS eben besonders gerne die eigenen Tools sähe, was keine Schande ist). Ich denke letzteres wäre für WP irgendwie angebracht. --Chrissolon 15:58, 19. Jan. 2007 (CET)

Ich stimme mit Dir überein, dass Code-Behind ein großer Vorteil ist. Um diese Frage geht es aber überhaupt nicht. Nur während der Codeabschnitt mit den Deklarationen der auf der aspx bzw. ascx-Seite befindlichen Controlls in der Vorläuferversionen vom Entwickler bearbeitet werden konnte, ist dieser Teil nicht mehr zugänglich. Nur beim Debuggen sieht man, dass tatsächlich Code generiert wird. Da nicht die IDE dafür verantwortlich ist, kann man die automatische Erzeugung des Deklarationsabschnitts auch nicht so ohne weiteres umgehen.

Wer nun eine Seite oder ein Control von einer Basisklasse ableitet und dort die Deklarationen der Controls vorgenommen hat, wird diese Seite über .NET 2.0 (in einer Web-Site) nicht zum Laufen bekommen. Und genau darum geht es in diesem Punkt. Wie Du richtig erkannt hast, ist dieses Verhalten unabhängig von der IDE und allein dem neuen Web-Modell geschuldet. Im Zuge dieser Umgestaltung der Architektur hat Mircosoft auch die Attribute der Page-Direktive geändert und die von mir geschilderten Inkompatibilitäten gegenüber .NET 1.1 und .NET 1.0 verursacht. Auch diese Änderung hat nichts mit der IDE zu tun. Der Hinweis auf das Patch ist u.U. als veraltet anzusehen, da nun mit SP1 die alten Web-Projekte mit den entsprechenden Page-Direktiven wieder möglich sind. Die Thematik der Web-Projekte im Vergleich zu den neuen Web-Sites birgt einigen Sprengstoff für die Zukunft von ASP.NET. Dieser Bereich müsste daher meines Erachtens sogar noch weiter ausgebaut werden, da es weitere wesentliche Unterschiede der beiden Ansätze gibt, die die Architektur der umgesetzten Anwendungen entscheidend beeinflussen.

Ich war übrigens zusammen mit weiteren Entwicklern damit beschäftigt, mehrere .NET-1.1-Anwendungen zunächst auf Whidbey und schließlich auf .NET 2.0 zu portieren. Von daher kannst Du mir glauben, dass ich aus Erfahrung spreche. Da .NET zu meinen Schwerpunkten gehört, will ich mir auch den Vorwurf des MS-Bashings nicht gefallen lassen. Nicht desto trotz stimme ich mit Dir überein, dass in dem Artikel einige seltsam formulierte Thesen enthalten sind, die den gesamten Artikel in einer Schieflage erscheinen lassen.--Sesalo 15:01, 20. Jan. 2007 (CET)

Der Artikel gehört dringend überarbeitet. Die Nachteile stimmen absolut nicht. 193.151.63.4 (Diskussion • Beiträge • Sperrlogbuch • sperren • Whois)

dann tu es - und begründe es sorgfältig mit Quellen - ganze Absätze rauslöschen, nur weil Du dafür zu faul bist, ist nicht drin. Andreas König 22:57, 23. Jan. 2007 (CET)

Zum Ersten "Ebenfalls nachteilhaft ist der Verzicht von ASP.NET 2.0 auf Projektmappen,...", dies ist kein Nachteil von ASP.NET 2.0 sondern ein neues Feature des Visual Studio 2005, und ausserdem hat Microsoft bereits einen Patch zur Verfügung gestellt, mit dem sich Web-Projektmappen wieder erstellen lassen.

Genau das wird im Beitrag so erwähnt. Es geht gar nicht so sehr um das Verhalten von Visual Studio sondern um die grundlegende Stoßrichtung von Microsoft. Wie stellt sich Microsoft den Aufbau von Web-Anwendungen vor. In welche Richtung möchte Microsoft gehen, wenn Projektmappen aufs Abstellgleis gestellt werden und stattdessen ein neues Konzept von Web-Anwendungen entwickelt wird, in dem z.B. jede einzelne Seite separat kompiliert werden kann und statt dessen die Einheit der gesamten Anwendung in den Hintergrund gerückt wird, usw., usw.. Es geht um Technologie-Diskussion, die ohne die üblichen Scheuklappen geführt werden muss, sonst hat sie in Wikipedia nichts zu suchen. Man muss ja nicht gleich beleidigt sein, weil auf ein paar Nachteile hingewiesen wird.--Sesalo 09:31, 1. Feb. 2007 (CET)

"Die von ASP.NET verwendete Technik zum Speichern der ViewStates führt dazu, dass die vom Browser aufgerufenen Seiten unnötig groß und..". Die ViewState Technik ist ein nützliches Feature, und lässt sich von jedem Control deaktivieren (-> Viewstate Code kleiner), oder man kann sie auch ganz abschalten (mit der angabe EnableViewState="false" im Page-Header)

"ASP.NET ist für eine „normale“ Privatperson eher ungeeignet, da es einerseits für kleine Projekte überdimensioniert..": ASP.NET eignet sich bestens für kleine Projekte, Gästebücher, Blogs, Fotoalben lassen sich mit ASP.NET viel schneller und einfacher realisieren also wie zB. mit PHP, .NET Webspace ist auch nicht mehr teuer, Ausserdem gibt eine einfache abgespeckte gratis Entwicklungsumgebung "Visual WebDeveloper", und einen gratis SQL Server 2005 Express. 193.151.63.4 (Diskussion • Beiträge • Sperrlogbuch • sperren • Whois)

Das Problem an diesem Artikel ist, dass er keinerlei sinnvolle Erklärung bietet und stattdessen wahllos zusammenkonstruierte Nachteile hinwirft. Die Abgrenzung zum alten ASP (ohne .NET) als Einleitung ist unsinnig, da die Technologien bis auf Namensteile und Hersteller nichts gemein haben. Man fängt als Umsteiger quasi bei Null an - das sieht auch MS so. Würde mal jemand grundsätzlich erklären wie die Verarbeitung von ASP.NET funktioniert (Code-Behind, Controls, Lebenszyklus), welche Rolle der Viewstate dabei spielt und wie stark man an eine IDE gebunden ist (s.o.), könnte man auch entsprechend ausgewogen Vor- und Nachteile anführen. So ist das aber garnichts und wir hängen uns nur an Kleinigkeiten auf. Und bevor jetzt die "Selber-besser-machen" Sprüche kommen: Ich überlege auch schon ein Konzept, bin aber auch anders gebunden und will nicht aus Zeitmangel nur MS rezitieren. --Chrissolon 19:40, 25. Jan. 2007 (CET)

[Bearbeiten] Weiteres Vorgehen

Ich finde es schon bemerkenswert, was für eine Wendung die Diskussion genommen hat. Und ich bin Andreas König dankbar, dass er die destruktiven Eingriffe von 193.151.63.4 (Diskussion • Beiträge • Sperrlogbuch • sperren • Whois) abgewehrt hat, der ja außer einer Pauschal-Wertung nichts, auch wirklich nichts zur Diskussion beigetragen hat. So kommt man nicht weiter. Ich finde den Vorschlag von Chrissolon nicht schlecht, erst mal ein übergreifendes Konzept für den Artikel zu entwickeln. Zu Beginn des Artikels sollte zunächst strukturiert erklärt werden, welcher Ansatz hinter ASP.NET steckt, wie dieser Ansatz gegenüber anderen Technologien (Beans, Tag-Bibliotheken, etc.) einzuordnen ist. Im Anschluss sollten die einzelnen Techniken erklärt werden, die grundlegend für den Aufbau von ASP.NET-Anwendungen sind.

Ich halte nichts davon, die auf für Entwicklung von ASP.NET-Anwendungen von Microsoft geschaffenen Tools in Visual Studio von ASP.NET abzutrennen, da ansonsten die Technologie-Diskussion keinen Sinn macht. So könnte man theoretisch mit .NET auch Web-Anwendungen schreiben, die genauso funktionieren wie JavaBeans, JSP-Tags, Struts usw.. Es ist unschwer zu erkennen, dass eine solche Herangehensweise in der absoluten Beliebigkeit endet. Dann müsste man auch das Code-Behind-Konzept, das View-State-Konzept und andere Erfindungen von Microsoft nur als eine mögliche Variante unter duzend anderen Varianten einer ASP.NET-Anwendung betrachten. Was macht dann ASP.NET aus??? Man sollte auf jedem Fall die Vorstellungen von Microsoft zum Aufbau einer Web-Anwendung ernst nehmen und entsprechend bewerten. Dass dabei immer wieder die Rede auf Visual Studio kommt, ist, wenn man es so betrachtet, nicht mehr als Zufall zu bewerten.--Sesalo 09:31, 1. Feb. 2007 (CET)

---