Advertisement
  1. Code
  2. Editorials

Warum viele Entwickler ASP.NET hassen... und warum sie sich irren

by
Read Time:18 minsLanguages:

German (Deutsch) translation by Valentina (you can also view the original English article)

Nur wenige Plattformen ziehen so viel Ärger wie ASP.NET (oder .NET im Allgemeinen) aus der Entwicklergemeinschaft. Zwar gibt es durchaus berechtigte Kritikpunkte an der Plattform (welche Plattform nicht?), Aber der Großteil der Negativität kommt von denen, die keine Zeit mit .NET verbracht haben. Diese Entwickler verlassen sich normalerweise auf falsche Vorstellungen oder Hass, um ihre Meinung zu begründen, und sie tun anderen, die eine neue Technologie erlernen möchten, und der Plattform selbst einen schlechten Dienst. Lassen Sie uns diese Ausreden untersuchen und eine Dosis Realität hinzufügen, warum Sie nicht auf das Gesindel hören und ASP.NET ausprobieren sollten.


Es wurde von Microsoft hergestellt

Dies ist wahrscheinlich der Hauptgrund für jeglichen Hass auf ASP.NET.

Microsoft ist ein riesiges Softwareunternehmen, und wie alle anderen Unternehmen sind sie im Geschäft, um Geld zu verdienen. Duh, richtig? Leider ist dies wahrscheinlich der Hauptgrund für all den Hass auf ASP.NET: Es handelt sich um eine Microsoft-Technologie, und der „böse“ Makel bleibt in den Köpfen vieler Menschen immer noch über dem Riesen. Ich fand das immer interessant, weil die anderen großen Technologieunternehmen wie Google und Apple genauso "böse" sind wie Microsoft, aber die Eiferer Fans dieser anderen Unternehmen blenden diese „Übel“ normalerweise aus (oder leugnen sie). Ich persönlich denke, die Mehrheit der Menschen sind normal denkende Menschen. Es ist ihnen egal, wer ein Produkt herstellt, solange dieses Produkt gut funktioniert.

Aber ich spreche nicht von normalen Menschen, oder? Normale Leute sehen keine Überschrift mit "ASP.NET" und haben automatisch den Drang, einen verrückten Kommentar abzugeben. Stattdessen spreche ich über die Entwickler (und Geeks), die Technologie behandeln, und/oder das Unternehmen, das sie erstellt, als Religion. Ich mache keine Witze - finden Sie einen Artikel oder ein Tutorial auf der X-Plattform, und die Chancen stehen gut, dass Sie Kommentare mit der Aufschrift "X Sucks! Y-Regeln! "

Es ist, als ob diese Leute sich auf einem seltsamen Kreuzzug befinden, um ihre gewählte Technologie/Firma bis zum Anschlag zu verteidigen und die Konkurrenz zu schlagen, um die ungewaschenen Massen in ihre Reihen zu bringen.

Es ist traurig, dass die Einstellung technology = religion existiert. Technologie ist ein gerechtes Werkzeug, und ein echter Entwickler wird mehrere Werkzeuge ausprobieren, um das richtige für den Job zu finden. Das heißt nicht, dass jemand eine Technologie nicht ablehnen kann, sondern dass unsere Eltern sagen: "Sie wissen nicht, dass Sie sie nicht mögen, bis Sie es versuchen." Damit jemand etwas wirklich nicht mag, muss er es versuchen. Hören Sie also nicht auf das Gesindel - sie haben es nicht versucht und sich keine informierte Meinung gebildet. Wenn Sie sich entscheiden, es zu versuchen, werden sie versuchen, Sie davon abzubringen, indem sie sagen, dass es zu viel kostet.


Missverständnis: Es ist teuer

Wenn Sie einen Artikel finden, in dem ASP.NET mit einer anderen Plattform verglichen wird, lesen Sie entweder im Artikel oder in den Kommentaren: "ASP.NET kostet mehr als [fügen Sie hier eine andere serverseitige Technologie als ColdFusion ein]." Bevor auf die tatsächlichen Kosten von etwas eingegangen wird, ist es wichtig, den Begriff "teuer" in einen Zusammenhang zu bringen, da das, was für den persönlichen Gebrauch teuer ist, in einem Geschäftsumfeld als billig angesehen werden kann. In der Wirtschaft gibt es viele Faktoren, die die „Kosten“ eines Produkts ausmachen. Der anfängliche Preis muss natürlich berücksichtigt werden, aber der Nutzen des Produkts wird auch in die Gesamtkosten einbezogen.

Wenn ein Produkt 10.000 US-Dollar kostet, das Unternehmen aber monatlich 1.000 US-Dollar einspart, ist die Kaufentscheidung ein Kinderspiel. Auf persönlicher Ebene wäre es jedoch höchstwahrscheinlich schwierig, die anfänglichen Kosten von 10.000 USD zu rechtfertigen.

Wenn es um Kosten geht, ist es wichtig, die Dinge entsprechend dem Kontext, in dem sie anfallen, im Blick zu behalten. Um die Dinge einfach zu halten, gehe ich davon aus, dass Sie sich beim Lesen mehr mit den persönlichen Kosten als mit den Geschäftskosten befassen (wenn ich mit dieser Annahme falsch liege, mache ich dies sehr einfach Sie: Wenn Sie eine Windows-Umgebung haben, ist ASP.NET billig.

Dank des Mono-Projekts benötigen Sie Windows nicht, um ASP.NET-Apps zu entwickeln.

Lassen Sie uns die größten Kosten aus dem Weg räumen: das Windows-Betriebssystem. Dank des Mono-Projekts (dazu später mehr) benötigen Sie Windows nicht, um ASP.NET-Apps zu entwickeln. Mono bleibt jedoch in der Regel hinter dem offiziellen .NET Framework zurück, das aus den Microsoft-Öfen stammt. Wenn Sie also die neuesten Funktionen und die .NET-Qualität nutzen möchten, benötigen Sie Windows. Die meisten OEMs (Unternehmen wie Dell, HP, Acer usw.) liefern ihre Computer mit bereits installiertem Windows aus. Wenn Sie Ihren Computer also in einer Elektronikkette wie Best Buy kaufen, stehen die Chancen verdammt gut, dass der Computer über Windows verfügt. Wenn Sie eher ein Hauptbenutzer sind und Ihre eigenen Computer bauen oder Windows in einer virtuellen Maschine ausführen möchten, müssen Sie eine Kopie von Windows erwerben. Eine OEM-Version von Windows kostet zwischen 99 und 189 US-Dollar, je nachdem, welche Windows-Version Sie kaufen. Sie müssen weder Professional (139 US-Dollar OEM) noch Ultimate (189 US-Dollar OEM) haben, aber wenn Sie ein Power-User sind, sollten Sie sich höchstwahrscheinlich für eine dieser beiden Versionen entscheiden (OEM-Versionen sind billiger als im Einzelhandel) Versionen, aber sie sind an die Hardware gebunden, auf der Sie sie aktivieren).

Entwicklungskosten

Lassen Sie uns die Entwicklungskosten überprüfen. Die Entwicklung von ASP.NET wird aus zwei Gründen als teuer angesehen.

  1. Es ist Microsoft. Sie verschenken angeblich nichts umsonst, aber genau das tun sie. Alles, was Sie zum Entwickeln von ASP.NET-Anwendungen (oder .NET-Apps im Allgemeinen) benötigen, können Sie ohne einen Cent erhalten.

    Anfänger: Zunächst verlost Microsoft WebMatrix, eine Entwicklungsumgebung für Anfänger. Es kombiniert eine integrierte Entwicklungsumgebung (IDE) mit einem integrierten Webserver (IIS Express) und einem Datenbankmodul (SQL Compact Edition). Es enthält auch Werkzeugs, mit denen Benutzer ihre Websites auf einem Remote-Host bereitstellen können.

    Fortgeschrittene Benutzer: Für fortgeschrittene Entwickler stellt Microsoft die Express-Editionen von Visual Studio zur Verfügung. Wie WebMatrix sind diese reduzierten Versionen von Visual Studio kostenlos, bieten jedoch einige der Funktionen und Fähigkeiten, die in den Vollversionen von Visual Studio enthalten sind. Das weborientierte Express-Produkt ist Visual Web Developer Express (VWD) und verfügt ebenfalls über einen integrierten Webserver. Es verfügt nicht über ein integriertes Datenbankmodul, aber Microsoft gibt SQL Server Express heraus, eine abgespeckte Version von SQL Server, die Sie für die Entwicklung (und sogar für einige Bereitstellungssituationen) verwenden können. Wenn Sie später entscheiden, dass Sie Visual Studio mögen und die Vollversion erwerben möchten, können die mit VWD entwickelten Projekte mit Visual Studio geöffnet werden.

    Studenten: Und wenn Sie Student sind, können Sie über das DreamSpark-Programm kostenlos viele Microsoft-Programme (Visual Studio Pro, Windows Server-Betriebssysteme und Expression Studio, um nur einige zu nennen) kostenlos herunterladen.

  2. Zweitens wird Windows-basiertes Hosting als sehr teuer angesehen. Vor zehn Jahren hatte dieses Argument etwas Gewicht. Heutzutage gibt es jedoch keinen Mangel an preisgünstigem Hosting für ASP.NET. DailyRazor (die Firma, die ich benutze) startet Pläne für 2 US-Dollar pro Monat, und Sie können andere Hosting-Anbieter finden, die ihre Dienste zu niedrigen Preisen verkaufen.

Die Kosten sind also kein wirkliches Problem, aber Neinsager werden dann sagen, dass ASP.NET nur für Websites der Enterprise-Klasse geeignet ist, im Gegensatz zu Ihren persönlichen Websites.


Missverständnis: Es ist schrecklich für kleine, persönliche Websites

Man muss sich nur die Klassenbibliothek von .NET Framework ansehen, um das Gefühl zu bekommen, dass dies für Unternehmen ist.

Es ist eigentlich einfach, sich vorzustellen, dass ASP.NET nur für große Websites geeignet ist. Microsoft ist schließlich ein Plattformunternehmen, dessen Produkte in erster Linie auf Geschäftslösungen ausgerichtet sind. .NET ist in dieser Hinsicht nicht wirklich anders. Es ist in Geschäftsumgebungen enorm und wächst weiter, da Microsoft neue und revitalisierte Produkte wie Azure (Microsoft Cloud-Plattform) bzw. Windows Phone erweitert. Man muss sich nur die Klassenbibliothek von .NET Framework ansehen, um das Gefühl zu bekommen, dass dies für Unternehmen ist. Es ist fast so, als würde das Framework Entwickler zu der Einstellung führen, dass (ASP) .NET-Anwendungen hoch strukturierte Meisterwerke des objektorientierten Designs sein müssen. Viele .NETs sind komplex und einfache Dinge zu tun ist nicht immer so einfach, wie es sein sollte. Es hört sich so an, als würde ich den Fall des Neinsagers machen, nicht wahr? Ich bin es irgendwie, aber es gibt zwei Dinge zu beachten.

Einfachheit

Erstens möchte Microsoft, dass Sie auf ihrer Plattform entwickeln, und sie haben erkannt, dass einige (möglicherweise viele) Vereinfachungen erforderlich sind, um zu wachsen. Schließlich ist PHP aufgrund seiner Einfachheit ebenso beliebt wie speziell. Dies ist der Hauptgrund, warum Microsoft WebMatrix veröffentlicht hat: neuen Entwicklern (entweder für die .NET-Entwicklung oder die Webentwicklung im Allgemeinen) einen vereinfachten Ansatz zum Schreiben von Websites mit ASP anzubieten. NETZ.

Die All-in-One-IDE ist nicht nur einfach zu verwenden, sondern Microsoft hat auch eine vereinfachte API erstellt, um die ASP.NET-Entwicklung einfacher und weniger komplex zu gestalten.

Mehrere Ansätze

Sie können auch Websites mit der gleichen Art von "Scripting"-Mentalität erstellen, die in PHP gedeiht.

Zweitens müssen Sie nicht in die Mentalität "hoch strukturiert oder sterben" fallen. Es gibt viele Ansätze für die ASP.NET-Entwicklung. Wenn Sie hochstrukturierte Meisterwerke objektorientierten Designs schaffen möchten, können Sie dies. Sie können aber auch Websites mit der gleichen Art von "Scripting" -Mentalität erstellen, die in PHP gedeiht. Der Punkt ist, dass die ASP.NET-Entwicklung flexibel genug ist, um Ihren Anforderungen zu entsprechen, und Sie können den Entwicklungsansatz wählen, der am besten zu Ihnen passt.

Seltsamerweise gibt es eine weit verbreitete Idee, dass ASP.NET nicht für Websites der Enterprise-Klasse geeignet ist. o.0


Missverständnis: Es ist schrecklich für große Websites der Enterprise-Klasse

Ich habe ehrlich gesagt keine Ahnung, woher dies kommt, da ASP.NET, wie bereits erwähnt, im Unternehmensbereich hervorragende Leistungen erbringt. Aber nimm nicht nur mein Wort dafür. Lassen Sie uns eine reale Website (also ein Netzwerk von Websites) untersuchen, die unter ASP.NET ausgeführt wird.

Haben Sie jemals von StackOverflow.com gehört? Sie haben wahrscheinlich eine Q&A-Website für Entwickler (unabhängig von der Technologie). Es ist eine unschätzbare Ressource, die ich ziemlich oft besuche.

StackOverflow ist Mitglied des Stack Exchange-Netzwerks, einem Netzwerk von Q&A-Websites für eine Vielzahl von Themen: Server, Datenbanken, Legos, Science-Fiction, Autos usw. Derzeit befinden sich 71 Standorte im Netzwerk und es wächst weiter.

Die Leute im Stack Exchange Network sind ziemlich offen für ihr Netzwerk. Ein Großteil des auf der Site ausgeführten Codes ist Open-Source-Code und enthält häufig Informationen zum Netzwerk im Allgemeinen. In einem Blogbeitrag vom März 2011 gab Kyle Brandt einen Überblick über die Technologie, die das Stack Exchange-Netzwerk antreibt, sowie über den Datenverkehr, den das Netzwerk erhält. Beachten Sie, dass sich diese Informationen auf das gesamte Stack Exchange-Netzwerk beziehen. Es erhält monatlich 95 Millionen Seitenaufrufe und verarbeitet 800 HTTP-Anforderungen pro Sekunde. Diese Anforderungen werden von zwölf (ja nur zwölf) Windows-Webservern, zwei MS SQL Server-Servern, zwei Linux-Load-Balancern und zwei Linux-Caching-Servern verarbeitet (Fehler) -über Hardware ist in dieser Zählung nicht enthalten).

Lesen Sie diese Statistiken noch einmal - ich werde warten. Phänomenal, richtig? Es ist erstaunlich, dass nur zwölf Server, die viele verschiedene Websites bedienen, diese Menge an Datenverkehr verarbeiten. Dies ist ein Beweis dafür, wie gut die Server- und Anwendungsarchitektur von Microsoft ist.


Es ist statisch typisiert

Dynamische Sprachen beherrschen das Web. Sei es auf der Serverseite, wo Sprachen wie PHP, Ruby, Python und Perl leben, oder im Browser mit JavaScript, dynamische Sprachen sind das Rückgrat des Webs. Es ist nicht so, dass diese Sprachen besser sind, aber sie werden schnell übernommen, da dynamische Sprachen normalerweise leichter zu lernen und zu verstehen sind als statisch typisierte Sprachen.

Am Ende haben wir also eine riesige Community von Entwicklern, die nur dynamische Sprachen verwendet haben, und diese Community hat fast eine Abneigung gegen statische Sprachen.

Ich verstehe die Denkweise voll und ganz. Ich war einer dieser Menschen und verstehe den Wunsch, in der eigenen Komfortzone zu bleiben. Schließlich sind dynamische Sprachen nachsichtig, und in dieser Nachsicht liegt ein gewisser Trost.

Statische Sprachen haben ein striktes Typensystem.

Aber diese Nachsicht hat eine schlechte Seite. Wenn Sie nicht vorsichtig sind, können Sie ganz einfach Fehler in Ihre App einfügen. Normalerweise werden Sie diesen Fehler erst zur Laufzeit finden. Eine häufige Ursache für Fehler ist die Zuweisung eines anderen und unbeabsichtigten Werttyps zu einer kritischen Variablen. Hier kommt der Hauptvorteil statischer Sprachen ins Spiel: die Typensicherheit. Statische Sprachen haben ein striktes Typsystem, da eine Variable nur einen Werttyp enthalten kann (z. B.: Eine als Ganzzahl deklarierte Variable kann nur Ganzzahlwerte enthalten; sie kann keine Zeichenfolge oder Gleitkommazahlen enthalten). Wenn Sie einer Zahlenvariablen versehentlich eine Zeichenfolge zuweisen, werden Sie beim Kompilieren des Codes sofort über den Fehler informiert, da der Compiler Sie anhält und Sie auf den Fehler hinweist.

Die Typensicherheit kann auch die Typprüfung erleichtern, die Sie in dynamischen Sprachen durchführen müssen. Wie oft haben Sie beispielsweise Code wie den folgenden geschrieben, um sicherzustellen, dass die von einer Funktion akzeptierten Daten vom erwarteten Typ sind:

Dies ist eine einfache PHP-Funktion, die zwei Zahlen addiert. Um vorhersehbare Ergebnisse zu gewährleisten, muss unbedingt überprüft werden, ob die angegebenen Werte vom entsprechenden Typ sind (zugegebenermaßen ist die Typprüfung hier nicht vollständig; es gibt andere numerische Typen als Ganzzahlen). Andernfalls kann Ihre App zu unerwarteten Zeiten beschädigt werden. Schauen wir uns im Gegensatz dazu den C#-Äquivalentcode an:

Dieser Code definiert eine add()-Methode. C# ist die beliebteste .NET-Sprache und rein objektorientiert. Es gibt keine Funktionen; nur Methoden einer Klasse. Diese Methode akzeptiert zwei ganzzahlige Werte (gekennzeichnet durch das Schlüsselwort int vor den Bezeichnern a und b) und gibt einen ganzzahligen Wert zurück, der vor add durch int angegeben wird. Da C# eine statische Sprache ist, wird die Typprüfung vom Compiler durchgeführt - nicht von Ihnen. Wenn Sie diese Methode aufrufen, eine Zeichenfolge als eines der Argumente übergeben, z. B. add ("hello", 123), und versuchen, den Code zu kompilieren, stoppt der Compiler den Erstellungsprozess und macht Sie auf den Fehler aufmerksam. Es besteht jedoch die Möglichkeit, dass Sie nicht einmal versuchen, den Code zu kompilieren, da Visual Studio eine eigene Typ- und Syntaxprüfung durchführt. Die IDE warnt Sie vor Fehlern, bevor Sie überhaupt versuchen zu kompilieren (siehe den folgenden Screenshot von Visual Studio 2010).

Beachten Sie auch, dass Microsoft die C#-Sprache ständig aktualisiert und verbessert. In den ersten beiden Versionen der Sprache mussten Sie den Typ einer Variablen identifizieren, wenn Sie sie wie folgt deklarieren:

Dieser Code erstellt eine Instanz der XmlDocument-Klasse, indem ihr Typ vor dem Namen der Variablen deklariert wird. Zugegeben, diese Syntax ist ziemlich umständlich und fügt viel mehr Typisierung hinzu. Ab C# 3.0 können Sie jedoch einfach das var-Schlüsselwort verwenden, um eine Variable wie folgt zu definieren:

Es gibt .NET-fähige Versionen von PHP, Ruby, Python und PERL.

Der Compiler ist intelligent genug, um zu schließen, dass die document-Variable ein XmlDocument ist. Diese Syntax verwischt die Grenze zwischen dynamischen und statischen Sprachen. Sie erhalten einfache, typenlose Variablendeklarationen mit den Vorteilen der Typensicherheit... eine Win-Win-Situation in meinem Buch.

Aber wenn ich Sie immer noch nicht davon überzeugen kann, C# auszuprobieren, müssen ASP.NET-Sites nicht in C# geschrieben werden (oder sogar in VB.NET... aber wer würde das tun wollen?). Es gibt .NET-fähige Versionen von PHP, Ruby, Python und PERL (und anderen), mit denen Sie ASP.NET-Sites schreiben können, und sie sind dank der Dynamic Language Runtime, einer Funktion von, genauso dynamisch wie gewöhnlich .NET 4. Während ich jedem empfehle, ASP.NET zu erlernen, um C# zu lernen, müssen Sie Ihre Komfortzone nicht verlassen, wenn Sie nicht möchten (aber wenn Sie dies tun, sind die Vorteile es wert).


Es ist kompiliert

Dieselben dynamischen Sprachen, die das Web beherrschen, werden ebenfalls interpretiert, und interpretierte Sprachen bieten einen gewissen Vorteil. Im Gegensatz zu kompilierten Umgebungen wie ASP.NET, in denen Sie Ihren Code normalerweise schreiben, kompilieren und hochladen, können Sie in interpretierten Umgebungen einfach Ihren Code schreiben und hochladen. Die übliche Idee ist, dass kompilierte Umgebungen einen zusätzlichen Entwicklungsschritt erfordern und dies Zeit verschwendet. Aber das tut es wirklich nicht. Der Compiler bietet uns viele Vorteile, die Sie in einer Umgebung mit interpretierten Sprachen einfach nicht erhalten können.

Zunächst überprüft der Compiler den Code und kann Sie warnen. Warnungen sind genau das: eine Warnung. Es ist etwas, das Sie getan haben, das vielleicht ein Fehler ist, aber es wird den Compiler nicht davon abhalten, Ihren Code zu kompilieren. Schauen wir uns den folgenden Code an, der eine Warnung auslösen würde:

Dieser Code definiert eine Methode namens DoSomething(). Sein Körper erstellt zwei String-Objekte, foo und bar, und foo wird an den Aufrufer zurückgegeben. Die bar-Variable wird nicht verwendet, daher würde der Compiler eine Warnung ausgeben, die besagt, dass bar zugewiesen ist, sein Wert jedoch niemals verwendet wird. Es kann sein, dass ich bar erstellt und diese vergessen habe oder dass ich sie letztendlich nicht brauchte. Aber es könnte die Ursache eines Fehlers sein, wenn ich vergesse, dass bar bereits existiert und ihn an anderer Stelle in der Methode verwendet. Der Compiler macht mich darauf aufmerksam, damit ich es beheben und zukünftige Fehler vermeiden kann. Hier ist ein Screenshot dessen, was Visual Studio mir sagt:

Wollen Sie noch ein Beispiel? Natürlich tun Sie das:

In dieser Methodendefinition wird eine boolesche Variable, foo, als true definiert. Es wird dann in einer if-Anweisung verwendet, in der der Wert false zugewiesen wird. Das mag genau das sein, was ich beabsichtigt habe (obwohl ich argumentieren würde, dass ich das niemals tun sollte), aber wahrscheinlich meine ich foo == false (ja, das logische nicht ! Operator wäre hier besser... aber es funktioniert nicht für mein Beispiel). Es ist jedoch kein Fehler, daher kompiliert der Compiler den Code. Es wird jedoch eine Warnung ausgegeben, in der gefragt wird, ob ich == anstelle von = gemeint habe. Dies sind Probleme, bei denen ich eine interpretierte Umgebung gefunden hätte, aber ich hätte die App ausführen und testen müssen, um diese Fehler zu finden.

Zweitens überprüft der Compiler den Code auf Fehler. Natürlich kann ein Compiler keine logischen Fehler abfangen, aber er kann check eingeben und die Syntax des Codes überprüfen. Eine anständige IDE erledigt diese Aufgaben für Sie, ohne dass ein Compiler erforderlich ist, und Visual Studio.

Zuletzt erhalten Sie einen Leistungsschub. Kompilierter Code wird schneller ausgeführt als interpretiert. Zugegeben, .NET ist keine wirklich kompilierte Umgebung. Unser Code wird in eine Zwischensprache (IL) kompiliert, die dann just-in-time von der .NET-Laufzeit kompiliert wird. Die IL wird jedoch optimiert und von der .NET-Laufzeit ausgeführt. Aber es ist immer noch sehr schnell.

Tatsächlich ist die Rohleistung von ASP.NET schneller als die von PHP.


Missverständnis: Es ist geschlossen

Microsoft stellt den Quellcode für .NET Framework kostenlos zur Verfügung.

Microsoft ist ein Unternehmen, das Software verkauft, und sie schützen natürlich den Quellcode ihrer Produkte sehr. Man könnte also denken, dass ASP.NET (und .NET im Allgemeinen) eine geschlossene Quelle ist, aber das ist nicht der Fall. Microsoft stellt den Quellcode für .NET Framework kostenlos zur Verfügung, und Sie können beim Debuggen Ihrer eigenen Apps in den Code eintreten. Sie können sogar Ihre eigene persönliche Version von .NET Framework erstellen.

Microsoft bietet Ihnen auch Zugriff auf den Quellcode von ASP.NET-Versionen wie WebForms und MVC über CodePlex. Sie können neue Funktionen testen und dem ASP.NET-Team Feedback geben. Ich ermutige jeden Entwickler, der .NET verwendet, diese kostenlosen Ressourcen herunterzuladen und zu studieren. Sie erhalten ein besseres Verständnis dafür, wie es unter der Haube funktioniert, und Sie können dasselbe Wissen beim Schreiben Ihres eigenen Codes anwenden.


Es ist nur Windows

Die Offenheit von Microsoft für .NET Framework hat dazu beigetragen, das Mono-Projekt, eine plattformübergreifende Version von .NET Framework, ins Leben zu rufen. Obwohl Mono von Microsoft nicht offiziell unterstützt wird, wurde das Projekt von Microsoft öffentlich anerkannt. Mono geht nicht weg. Tatsächlich wird es immer beliebter Unabhängig von Ihrer bevorzugten Plattform können Sie wahrscheinlich .NET Framework und C# verwenden, um Apps dafür zu schreiben (Sie können sogar iOS-Apps mit Mono schreiben!).


Es ist nicht gefragt

Schließlich wird oft behauptet, dass ASP.NET nicht gefragt ist, und das ist einfach nicht wahr. Die Nachfrage ist etwas subjektiv, da verschiedene Regionen der Welt und in dem Land, in dem Sie leben, unterschiedliche Arbeitsmärkte haben. In jeder Hinsicht war .NET in den letzten zehn Jahren die Entwicklungsplattform für Microsoft Windows-Umgebungen (sowohl für den Desktop als auch für das Web).

Die meisten für Windows entwickelten Programme verwenden .NET Framework. Daher besteht für neue .NET-Entwickler eine große Chance, Arbeit zu finden.

Das Mono-Projekt berücksichtigt auch die Nachfrage. Mono ist riesig und die Community wird immer größer. Dank der umfassenden Unterstützung des Betriebssystems können Sie Apps für alle großen Betriebssysteme, einschließlich mobiler Geräte, schreiben. Unabhängig vom Betriebssystem gibt es jede Menge Möglichkeiten!


Schlussfolgerung

Wo bleibt uns das alles? Nun, die Hasser und Neinsager sind falsch, und ASP.NET ist eine Technologie, die Sie ausprobieren sollten. Erfolgreiche Entwickler sind schließlich Polyglotten, die Anwendungen in verschiedenen Sprachen für verschiedene Plattformen schreiben können. Probieren Sie ASP.NET aus. Was sagen Sie?

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.