Diskussion:ASP.NET/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:ASP.NET/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:ASP.NET/Archiv/1#Thema_1

subsequent

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)

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.
Wie wäre es mit einer Anpassung der "aktuellen Versionsangabe" auf der ganzen Seite? (Rechts ist 2.0 und oben ist 3.0)

--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)

Also ich versuche das Ganze etwas umzustrukturieren! Hab soeben die Punkte "Tools zur Erstellung" (vorher Software) und "Webserver" etwas klarer versucht darzustellen. Vor allem das mit dem XSP und mod_mono war total falsch. Werde versuchen in nächster Zeit Dinge wie Page-Life Cycle und ähnliches einzubauen. Auch ViewState sollte näher erklärt werden, kaum einer der mit ASP.NET anfängt bekommt da gleich ein gutes Bild davon. Code-Behind-Klassen bereits vor der Laufzeit von der Entwicklungsumgebung kompiliert werden - Das halte ich für ein Gerücht, dann müsste die Umgebung ja ständig am Kompilieren sein und man könnte sich das Neukompilieren sparen. Es stimmt aber, dass das VS die Dateien schon syntaktisch durchparst und Fehler erkennt (und das zumindest seit VS 2005 sowohl in der aspx als auch im Code-Behind) --Cyber1000 01:51, 1. Sep. 2007 (CEST)

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)

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")

Ists nicht. Wird kompiliert und nicht interpretiert. --Sigemi 02:49, 17. Aug. 2009 (CEST)

Der letzte Absatz - "Die Abstraktion geht soweit, dass z.B. eine komplette Rechteverwaltung (User/Roles) – mitsamt Login, „Passwort vergessen“, und ähnlichem – fast ohne selbstgeschrieben Code, zumindest aber mit vorgefertigten Klassen in die eigene Seite implementiert werden kann.." - klingt sehr nach Marketing-gewäsch. Die vogefertigen Membership-/RoleProvider sind in der Praxis idr. unbrauchbar, weil sie letztlich nur ein Kompromiss bzw. "Showcase" aus den Benutzerverwaltungsmechanismen sind, die es bei einigen großen Seiten im Netz gibt, und die jeder so schonmal gesehen hat. Damit macht es sich in der Werbung und den Click&Läuft-ohne-eine-Zeile-gecodet-zu-haben-Videos zwar super, ist aber jetzt nicht das Killerfeature, das hier so groß hervorgehobenwerden müsste. Man könnte es allenfals als eien Referenzimplementation ansehen. Schlage vor den Absatz zu entfernen. --Sigemi 02:49, 17. Aug. 2009 (CEST)

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 • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)

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 • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)

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)

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 • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs) 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)

Also irgendwie scheint hier ganz verloren zu gehen, dass es mittlerweile ein ASP.NET MVC2 gibt, dass den Vorzug vor dem einfachen ASP.NET (auch der Version 4) erhalten sollte. (nicht signierter Beitrag von 95.222.248.164 (Diskussion) 21:46, 8. Aug. 2010 (CEST))

---

Allgemeine Frage

Sollten nicht Artikel von Leuten geschrieben werden, die eine Ahnung von der Materie haben, und kein MS Bashing betreiben wollen? Also, ich muß sagen, dass ich nicht das Gefühl hab, dass ich mich EXTREM gut mit der Materie auskenn, aber ich hab inzwischen soviel Ahnung, dass ich seh, dass vieles schlicht und einfach falsch ist. Ich geh nur kurz mal die Nachteile durch:

1) "Dass Weniger an Code (durch Codebehind) benötigt wird, wird mit einem deutlichen Nachteil an Kontrolle über die Programmausführung durch den Entwickler erkauft"

a) Wenn ich will, kann ich jedes einzelne Zeichen des HTML's rausjagen, ich sage nur

 protected override void Render( HtmlTextWriter writer )

Dann darf ich mich um alles selbst kümmern, und brauch mich nicht ärgern, weil ich nicht über alles Kontrolle haben will.

b) Google nach "ASP.NET Control Adaptors" Damit kann ich ebenfalls das, was ausgegeben wird, beeinflussen.

c) Codebehind hat doch bitte nix mit "weniger an Code" zu tun, sondern mit einer Trennung "Ansicht-Daten". Dass es damit zu weniger Code kommt, wenn ich nicht jedes Tag einzeln schreiben muß, ist ein Nebeneffekt, aber nicht der Grund.

d) Das ganze ergibt allerdings, wenn man es richtig macht, eine Site, die man einmal macht, die allerdings die Ausgabe an den aufrufenden Browsern anpasst.

Ich weiß nicht, ich seh darin nicht soviele Nachteile, eigentlich nur Vorteile. Wenn ich will, kann ich auch

writer.Writeln("<html><body>" + Request.QueryString["Param"] + "</body></html>")

schreiben. Macht nur keinen Sinn.

2) Projektmappen. Also, ich hab einiges schon in ASP.Net 1.1 und 2.0 gemacht, aber so schlimm ist mir das Problem, dass das nicht mehr möglich ist/sein soll, nie vorgekommen, dass der Punkt dreimalsoviel Platz annimmt wie ALLE Vorteile.

3) "ASP.NET ist für eine „normale“ Privatperson eher ungeeignet, da es einerseits für kleine Projekte überdimensioniert ist"

Warum soll das überdimensioniert sein? Visualstudio (zum entwickeln) ist konstenlos, Mono zum Anzeigen ist kostenlos. Man kann als Nachteil ansehen, dass man vielleicht 2 Minuten länger nach einem ASP.NET Hoster suchen muß, als für einen PHP Hoster, nur find ich z.B. solche "Nachteile" weder in Ruby, noch irgendwo anders. Hier ists ein "Nachteil"

4) Gründe dafür sind unter anderem die faktische Plattformabhängigkeit (wenngleich mit Mono eine Alternative existiert, die sich bereits in einem weit fortgeschrittenem Stadium befindet) sowie die höheren Lizenzgebühren für Windows-Server.

Ähm, warum ist etwas Plattformabhängig, wenns eine plattformunabhängige Alternative gibt?

etc.

Vieles in diesem Artikel ist in meinen Augen falsch und alles andere als objektiv...

Sogar bei dem einen Vorteil wurde ein Nachteil reingeschummelt (ASP.NET ist vor allem auf Grund des Funktionsumfangs schwieriger als andere Scriptsprachen wie beispielsweise PHP oder Perl zu erlernen), der komplett falsch ist.

Asp.net ist KEINE Scriptsprache oder Programmiersprache. Das ist schlicht und einfach falsch, und zeugt von einem absoluten Unverständnis. Asp.net Seiten können in C#, VB.Net oder Php entwickelt werden.

Wie "Php" schwerer zu erlernen sein soll als "Php", muß man mir erklären, wie "c#" oder "Vb.Net" schwerer zu erlernen sein soll als "Perl" genauso...

Oder "Des Weiteren soll 2007 mit .NET 3.0 WPF erscheinen, das ASP.NET im Rich-Client Bereich ablösen soll."

Was hat WPF mit ASP.Net zu tun? Genau NIX. Das ist so falsch als ob ich erklären wollen würd, dass UMTS in Zukunft das Internet ablösen soll...

--Tintifax73 15:59, 12. Jun. 2007 (CEST)

Moin

Du hast völlig recht. Nur ich für meinen Teil habe keine Lust mich mit den Anti-Bill-Rittern herumzuärgern und denke, dass es anderen auch so geht. Wenn Du Dich an den nötigen Verbesserungen versuchen willst, wünsche ich Dir viel Glück. -- Hgulf 16:26, 12. Jun. 2007 (CEST)

Selbst ist der Mann.

Ich habe jetzt die zwei Absätze über die Projektmappen entfernt. Dieses "historische" Thema kann zwar prinzipiell gerne im Artikel erwähnt werden, aber nicht in der Ausführlichkeit verglichen mit den deutlich wichtigeren Punkten.

Dieser eine Edit soll nicht bedeuten, dass ich mit dem restlichen Artikel glücklich bin ;)

-- Hgulf 08:28, 14. Jun. 2007 (CEST)

Hallo Leute.

Zu 1) Ich glaube an dieser Stelle ist das etwas anders gemeint. So steht weiter unten:

 wie es einem konsequenten Objekt-orientierten Ansatz entspricht.

Der ganze Absatz war vielleicht nicht besonders neutral, aber alles was der Autor damit sagen wollte ist imho, dass es einem diese Code-Behind-Idee von Microsoft schwieriger macht die Dinge aus OOP-Sicht "richtig" anzugehen. Klar kann man Render überschreiben - aber im Bezug auf OOP darf und kann das keine Alternative sein.

Zu 2) Habe das Problem mit den Projektmappen ehrlich gesagt nicht verstanden. Wo steht das überhaupt?

Zu 3) Auch hier ist das denke ich ein Ausdrucksproblem. Imho meint der Autor damit, dass ja ASP.NET als Sammlung von Technologien für den Durchschnittsuser viel schwerer zu lernen und zu handhaben ist als z.B. PHP. Das macht es definitiv zu einer "Schwäche" die es so bei Ruby etc. wirklich nicht gibt. Im Übrigen sind die Hosting-Angebote durch den kommerziellen Hintergrund teurer als Open-Source, auch das ist richtig. Wenn man diesen Absatz etwas anders ausdrückt hat er durchaus Bestand.

Zu 4) Das ist schlichtweg falsch, der Autor hat völlig recht. Man muss es mal ganz klar sehen, trotz der theoretischen Plattformunabhängigkeit die .NET grundsätzlich bietet kann man dennoch nie von Plattformunabhängigkeit reden. Es gibt keine Unterstützung durch Microsoft von non-Windows-Plattformen. Das es Open-Source Implementierungen wie Mono gibt ist schön, aber diese werden nie so schnell so gut sein wie die Referenzimplementierung unter der ASP.NET läuft. Neues .NET-Framework und schon hast du ein Problem. Zumal die Unterstützung auch nicht besonders gut sein soll (beim googlen habe ich noch nie von Leuten gehört die nicht negativ über ASP.NET/Mono berichtet hätten).

Das ASP.NET keine Programmiersprache ist, sollte jedem klar sein. Vielleicht ist das ungünstig ausgedrückt - aber wie gesagt, ich denke das ist eine Ausdrucksschwäche dieses Absatzes (s.o. "Zu 3").

Was WPF & ASP.NET angeht so ist denke ich nur gemeint das z.B. mit Silverlight gewisse ASP.NET-Bereiche "abgelöst" bzw. in Zukunft anders gehandhabt werden. Was regst du dich darüber auf? Vielleicht ist das (ebenfalls) nicht so verständlich ausgedrückt, aber es ist ja kein Nachteil.

Im Übrigen - jeden stört irgendwelches whatever-Bashing. Aber du machst es auch nicht besser, wenn du Anti-whatever-Bashing betreibst. Setz dich faktisch damit auseinander, rede mit anderen Leuten darüber, dann kann man den Artikel verbessern und die nötige Neutralität herstellen.

--Florian Sening 15:03, 7. Aug. 2007 (CEST)

Ich hab mich faktisch damit auseinandergesetzt, und schon lang verbessert, in meinen Augen ist er jetzt wesentlich neutraler als vorher. Wenn Du anderer Meinung bist, dann kannst Dich gern über den Artikel aufregen und ihn ändern, das bashen eines Post vom Juni ist somit unnötig...

--Tintifax73 10:30, 16. Okt. 2007 (CEST)

Meine Meinung noch eine Anmerkungen zu den Nachteilen. Der Abschnitt über den ViewState müsste man meiner Meinung nach streichen. 1. ViewState ist eine komfortable Möglichkeit Daten temporär zwischenzuspeichern. (Es gibt auch andere. Session, eigene HiddenFields, temporäre Files etc., Variable als URL Param mitgeben.). Jede dieser Möglichkeiten hat Vor- und Nachteile. Es liegt am Entwickler jeweils die am besten passende zu benutzen. Es ist meiner Meinung einfach eine weitere Möglichkeit die das Framework dem Programmierer bietet. Wenn schon den schon ist dies ein Vorteil, aber sicher nicht ein Nachteil. 2. ViewState ist wirklich gut dokumentiert. Soweit ich mich errinnern kann wird in allen Quellen (Bücker, Tutorials) erwähnt, dass man ViewState mit bedacht einsetzen soll um die Seite nicht aufzublähen. 3. ViewState ist eigentlich ein nur ein kleiner Teil des gesamten Asp.net Frameworks und sollte meiner Meinung nach in einem solchen Artikel keine Erwähnung finden. Also weder vorgestellt noch in einem Vor- oder Nachteil erwähnt werden. Ich werde diesen Teil darum entfernen.

70 Prozent

Braucht man nur 70 % oder 70 % weniger? Müsste doch jemand klarstellen können. Eine Quelle direkt von MS dafür wäre auch eine Verbesserung. --132.231.1.178 13:09, 8. Jan. 2008 (CET)

Moin

"Die neuen Dienste und Merkmale von ASP.NET 2.0 ermöglichen die produktivere Entwicklung von umfassenden Anwendungen für unterschiedlichste Szenarien. 45 neue Sicherheits-, Daten- und Webpart-Steuerelemente zum Beispiel gestatten es Programmierern, anspruchsvolle Websites und -anwendungen mit bis zu 70 Prozent weniger Code zu entwickeln."

(Quelle: Microsoft)

Schöne Grüße -- Hgulf Diskussion 14:17, 8. Jan. 2008 (CET)

Wenn hier schon eine Antwort steht, dann kann man das doch auch gleich für den Artikel nutzen. Hab es mal eingebaut. --Tobias K. 17:30, 13. Jan. 2008 (CET)

Hi, als relativ erfahrener Entwickler von Asp.net Applikationen kann ich sagen dass 70% für grössere Applikationen mit Sicherheit übertrieben ist. Bei kleineren Websites mag dies stimmen, bei grösseren Applikationen sollte man jedoch einige Dinge (z.B. Sql-Datasource) nicht unbedingt einsetzen, da diese schlecht skalieren, was dann auch zur Folge hat, dass man doch nicht so viel Code spart.

Das ist nur ein Marketing-Gag von Microsoft und richtet sich ausschliesslich an RAD (Rapid Application Developement) Entwickler. Dieses Konzept ist allerdings mehr als tötlich, wenn man nicht nur eine kleine Anwendung machen muss, die im Nachhinein nicht wirklich erweitert oder verändert werden soll.-- Peter Bucher 21:09, 22. Jul. 2009 (CEST)

PHP als .NET-Sprache

"Somit kann jede ASP.NET Webseite in allen .NET-Sprachen (z.B. C#, VB.NET oder auch PHP) programmiert werden" - PHP ist definitiv keine .NET Sprache. Evtl. ist ja J# gemeint, die fehlt nämlich in der Auflistung. Werde den Artikel diesbezüglich korrigieren -Sigemi 02:39, 17. Aug. 2009 (CEST)

zu viel Werbung

Dieser Artikel lest sich wie ein Werbeschreiben von MS. Ein Beipiel: Die "Unterschiede zu ASP" sind wohl nicht das wichtigste Merkmal von ASP.NET. Das ist nur für einen Werbetext sinnvoll. In der Wikipedia kann jeder selbst den Beitrag über den Vorgängers aufrufen. Ein Link zu ASP selbst würde ausreichen. Bei PHP werden auch nicht alle Unterschiede zu Perl erklärt. Statt "Werbung" für "Visual Studio" wäre es viel sinnvoller die Unterschiede der verschienden ASP.NET-Versionen zu erklären. Könnte man diesen Betrag nicht genau gleich strukturieren wie PHP? -- Thomei08 13:37, 11. Dez. 2009 (CET)

Gliederung

• Hat es einen Sinn dass "Zukunft" vor "Versionsgeschichte" erörtert wird? Sonst sollte das umsortiert werden.
• Wäre es möglich in der Tabelle der Versionsstände farblich zu kennzeichnen was aktuell ist, was in Entwicklung und was aktuell stable release ist? So wie unter Mozilla Firefox#Wichtige_Versionen zu sehen. Das wäre dann auch eine kleine optische Auflockerung.

--Hamburger 16:51, 18. Jun. 2011 (CEST)

Hab es mal geändert. Wenn jemand Unzulänglichkeiten entdecken sollte o.ä., bitte gleich korrigieren u. hier vermerken. Danke --Hamburger 17:48, 21. Jun. 2011 (CEST)

Zukunft

Dieser Abschnitt erscheint mir leicht veraltet.

• Silverlight ist seit einiger Zeit (mindestens 2009) schon samt SDK released und im produktiven Einsatz.
• Die Verbreitung von Silverlight ist gering (Konkurrenz zu HTML5/Flash) bzw. dürfte hinter den Erwartungen von MS zurückgeblieben sein
• "Microsoft hat für sich erkannt, dass HTML/CSS/JavaScript für Rich-Clients nicht mehr ausreichend ist." Keine der genannten Technologien war je ursprünglich dafür konzipiert, Rich Clients zu entwickeln, was hier fälschlich suggeriert wird. Es ist auch gar nicht mal unstrittig, dass Silverlights Primärzweck die Rich Client Entwicklung wäre. Diese Forumlierung ist mehr als unglücklich. Letzten Endes ist SL eher eine Basis für animierte interaktive Webinhalte. Es kann aber auch nicht das Ziel des ASP.net Artikels sein, Silverlight zu diskutieren.
• Informationen über zukünftig geplante Erweiterungen von ASP.net (zB hinsichtlich dem von MS viel beworbenen MVC Plugin), soweit schon bekannt, sollten hier Erwähnung finden. Falls aufgrund der proprietären Entwicklungsweise nichts über die nächsten Releases bekannt ist, sollte dies ("nichts bekannt") so vermerkt werden.

--Hamburger 17:39, 18. Jun. 2011 (CEST)

Hab auch hier mal selbst jetzt eingegriffen und den Abschnitt wesentlich modifiziert. Da Silverlight keine Zukunftsmusik mehr ist sondern released, steht es jetzt bei ergänzende Technologien. Wer noch mehr zur Zukunft weiß und beisteuern kann, ist herzlich eingeladen. --Hamburger 17:49, 21. Jun. 2011 (CEST)

Coolness-Faktor?

"sowie der Coolness-Faktor von Scriptsprachen wie PHP" - Was soll damit ausgedrückt werden, und passt dieser Ausdruck hier? (nicht signierter Beitrag von 217.233.246.251 (Diskussion) 08:43, 18. Jul. 2006 (CEST))

QS

Silverlight und Rich Clients sind nicht das einzige Problem an diesem Artikel. Eine Totalerneuerung wäre nötig. Wäre schön, wenn sich mal ein/eine Fachmann/frau den auf der QS genannten Problemen annehmen würde: Wikipedia:Redaktion_Informatik/Qualitätssicherung/Knacknüsse#ASP.NET Ich weiss nicht wer auf die Idee kam den QS-Eintrag zu entfernen. Davon sind wir noch weit weg. War in der QS nicht als erledigt markiert. Sorry. -- Thomei08 18:16, 21. Jun. 2011 (CEST)

Weitere Diskussion siehe Benutzer Diskussion:Thomei08#asp.net_qs --Hamburger 13:17, 27. Jun. 2011 (CEST)

Gestern diverse Informationen nach Vorlage des englischsprachigen Artikels hierher (nicht wortwörtlich) übertragen um den Informationsgehalt hier aufzupeppen. --Hamburger 21:39, 2. Jul. 2011 (CEST)

Schon mal viel besser... jetzt muss nur noch der ganze weiter unten noch bestehende "Werbetext" überarbeitet werden. -- Thomei08 23:45, 2. Jul. 2011 (CEST)

Weitere Umbauten erfolgt. Textuell ergeben sich kleine Unterschiede, einiges habe ich auch nur verschoben. Die Unterschiede zum (mittlerweile uralten) klassischen ASP sind weit weniger betont.

Probleme hinsichtlich einer Werbetext-Ähnlichkeit sehe ich nicht, zumal dafür nach wie vor keine stichhaltigen Argumente kamen. Dass eine so umfangreiche und mittlerweile lang etablierte Technologie wie ASP.NET auch Vorteile hat, steht außer Frage, sonst hätte sie ihren derzeitigen Marktanteil im Web wohl auch nicht erreicht.

Es stellt sich meiner Ansicht nach künftig die Frage nach der Daseinsberechtigung des Kurzartikels WebPart. Der ließe sich hier locker auch integrieren. --Hamburger 02:23, 5. Jul. 2011 (CEST)

Kompatibilität von Mono mit ASP.NET, veraltete Angaben

Kann das mal wer aktualisieren, die stabile Version von Mono unterstützt bis ASP.NET 4.0 und die aktuelle Version noch mehr. siehe http://www.mono-project.com/Compatibility --78.52.19.124 21:42, 11. Okt. 2013 (CEST)

Verbreitung

"Weil jedoch PHP mit Abstand die meistverwendete Skriptsprache für Webprogrammierung ist" würde ich zwar aus dem Gefühl unterscheiben, diese Behauptung müsste dennoch eine Referenz bekommen.--Hinnerk Weiler 08:25, 14. Feb. 2012 (CET)

PHP zitiert hierzu diesen Artikel. Wenn du magst, pflege ihn gerne als ref Tag ein oder vielleicht findest du ja deinerseits noch Statistiken zum gleichen Thema die die Aussage ebenfalls stützen (?). --Hamburger 13:43, 15. Feb. 2012 (CET)

"häufiger als Java" meint doch wohl Javascript (nicht Java) oder habe ich da grundsätzlich etwas falsch verstanden? (nicht signierter Beitrag von 2003:45:2B08:BE01:B91B:4653:C928:9A56 (Diskussion | Beiträge) 10:34, 14. Mär. 2013 (CET))

Wieso Javascript? Serverseitiges Javascript kenne ich nur aus der Literatur. Java als Programmiersprache für Web-Anwendungen ist hingegen durchaus verbreitet. -- Hgulf Diskussion 11:15, 14. Mär. 2013 (CET)

Ich habe entschwurbelt. Ich merke an, dass die Einzelnachweise in dieser Form sinnfrei sind, weil die Website keine Relevanz besitzt, nichts zum methodischen Vorgehen sagt und auch nichts zu den Quellen. Das PHP Platzhirsch ist, dürfte außer Frage stehen, warum das so ist, böte für den Leser des Artikels m. E. einen Mehrwert. --Crosby Newton (Diskussion) 23:29, 22. Okt. 2013 (CEST)

20,1% ASP.NET + 78,7% PHP + 4,1% JAVA > 100%

Ganz am Anfang heißt es: "Mittlerweile wird ASP.NET auf ca. 20,1 % aller Websites als serverseitige Programmiersprache eingesetzt[2] und ist damit die nach PHP (78,7 %) am häufigsten verwendete Sprache zum Erstellen von Websites. Sie liegt damit deutlich vor Java (4,1 %)." Das scheint einfach von der Quelle abgetippt zu sein. Java kommt in dieser Quelle wahrscheinlich aufgrund von Applets auf so hohe Werte (anders kann ich es nicht erklären), allerdings wird daraus deshalb noch keine serverseitige Programmiersprache. (nicht signierter Beitrag von MatorKaleen (Diskussion | Beiträge) 19:01, 1. Mai 2013 (CEST))

Ich habe die Formulierung angepasst. Java wird gerne dort eingesetzt, wo es sehr auf die Performanz ankommt - ich denke gerade an zwei Projekte, von denen ich die serverseitige Java-Verwendung her kenne. --Crosby Newton (Diskussion) 23:31, 22. Okt. 2013 (CEST)

korrekte Fachbegriffe

Seit wann ist ASP.NET eine "Programmiersprache"? C# und VB.NET sind die beiden Hauptsprachen im .NET-Umfeld. ASP.NET ist eine Technologieplattform und keine Sprache (genauso wenig wie HTML eine Programmiersprache ist). Das sollte unbedingt geändert werden. (nicht signierter Beitrag von Vbinsider (Diskussion | Beiträge) 10:39, 8. Apr. 2015 (CEST))

unverständlicher Inhalt

hallo liebe autoren, diese seiten ist für einen Menschen, der mit Informatik nicht zu tun hat, vollkommen unverständlich.--Francis McLloyd (Diskussion) 13:33, 29. Dez. 2013 (CET)