ASP.NET MVC 3 Tutorial #1 – Das Model View Controller (MVC) Pattern erklärt

Von Mario Meir-Huber Autor Feed 21. März 2011 22:31

Nachdem auf CodeFest noch etwas wenig Content zu Asp.NET MVC 3 vorhanden ist, habe ich mich dazu entschlossen eine neue Tutorial-Reihe zu diesem Thema zu starten. Im ersten Post möchte ich darstellen, was das MVC Pattern eigentlich genau ist, bevor wir uns auf ASP.NET MVC tatsächlich stürzen.

MVC steht nicht für “Mercedes Benz Veteranen Club” sondern für “Model-View-Controller”. Das MVC Pattern wurde erstmals 1978 durch Trygve Reenskaug beschrieben. Trygve arbeitete damals an Smalltalk. Da dieses Pattern bereits 33 Jahre  alt ist, gehört es definitiv zu den Urgesteinen der Software-Patterns. Heute findet man eine Vielzahl an MVC Frameworks für die unterschiedlichen Frameworks und Plattformen. Das MVC Pattern wird auch oft in etwas abgewandter Form verwendet, wie etwa dem MVP (Model View Presenter) und dem MVVM (Model View ViewModel) Patterns. Das MVC Pattern ist heutzutage eine Standardlektüre an jeder Universität und jeder Schule an der Softwareentwicklung gelehrt wird. Wie auch immer – mit ASP.NET MVC ist nun auch ein schlagkräftiges MVC Framework für .NET vorhanden.

image

Prinzipiell bietet das MVC-Pattern eine relativ große Flexibilität, welche von der jeweiligen Implementierung abhängt. Doch wofür stehen nun die eigentlichen Begriffe?

Model

Das Model stellt die Daten dar, welche für die Anwendung verwendet werden. Je nach Anwendung kann das beispielsweise eine Person, ein Produkt oder viele andere Dinge sein. In manchen Implementierungen wird die Geschäftslogik in das Model ausgelagert. Hierbei teilen sich die Meinung ob dies nun richtig oder falsch sei. Idealerweise sollte keine Logik im Model sein.

View

Der View dient der Anzeige der Daten und stellt dem Benutzer gewisse Interaktionsmöglichkeiten zur Verfügung. Dies können Beispielsweise Dateneingaben oder Datenmanipulationen sein. Wichtig ist jedoch, das der View auf gar keinen Fall Geschäftslogik enthalten darf. Der View ist nur eine Anzeige, nicht jedoch die Verarbeitung dieser Daten. In Asp.NET MVC gibt es einige ViewEngines, wie etwa Razor.

Controller

Der Controller hat die Aufgabe, Views anzuzeigen und das Modell an den View zu übergeben. Der Controller verarbeitet Benutzereingaben und leitet diese an die dafür zuständigen Layer weiter. In Asp.NET können die Controller sehr komfortabel über die URL des Browsers aufgerufen werden. Wie dies funktioniert wird in einem späteren Artikel erklärt.

Asp.NET MVC hat einige tolle Möglichkeiten, welche in den kommenden Wochen in weiteren Tutorials erklärt werden.

Weitere Informationen:

Kommentare (15) -

>

22.03.2011 00:36:42 #

Super Einstieg in das MVC-Thema°
Wir verwenden jetzt ebenfalls nach einem kurzen Rails-Ausflug wieder ASP.NET MVC und freuen uns besonders über die neue Razor ViewEngine.

Übrigens - wäre es nicht interessant mal einen Workshop für ASP.NET - Umsteiger zu veranstalten? Wir wären auf jeden Fall dabei!

Daniel Lang Austria

>

22.03.2011 07:44:50 #

Ich finde das MVC Pattern (und seine Kumpanen MVVM und MVP) wird immer zu technisch erläutert. Es geht immer um das das Wie und welche Regeln man nicht verletzen darf ( keine Logik im View).Schlussendlich muss man sich die Frage stellen, "Wenn das alles so toll ist, warum ist dann nach 33 Jahren nicht jeder 100%tig davon überzeugt?"
Viel zu selten geht es um das Warum.

Wenn man das Argument "Testbarkeit" mal weglässt (das brauchen faktisch 95% aller Dev's nicht) bleibt eben nicht viel über. Auf der anderen Seite steht ein erheblicher Mehraufwand um aus einer Zeile Code im UI 10 Zeilen Code im Controller zu machen. Nicht besonders sexy für die meisten.
Viel relevanter finde ich die herangehensweise in WPF und Silverlight. Das dortige Databinding folgt definitiv in weiten Teilen dem MVC Pattern. Der Vorteil aus der deklarativen Bindung ist eine Design Time Datensicht und das ist ein riesen Argument für alle die schicke LOB Anwendungen schreiben. Auch die validierungslogik rutscht dabei von ganz alleine aus der UI und damit dem View raus. Auch lassen sich asynchrone Szenarien, wie im Web üblich, per Databinding und seiner ObserveableCollection ganz wunderbar lösen. Aber ganz wesentich finde ich, wenn einmal ein Button Event im View auscodiert wird, ist der der Entwickler kein schlechter Mensch und der Code deswegen genauso lesbar (vielleicht sogar noch besser).

Hannes Preishuber Germany

>

22.03.2011 10:08:28 #

Hallo Hannes,
Ich verstehe dein Argument "95% der Dev's brauchen Testing nicht" - ist das jetzt sarkastisch gemeint oder bist Du tatsächlich der Meinung das nur 5% aller Entwickler deren Code testen bzw. testen wollen?

Im Prinzip ist es so: es gibt Asp.NET, Asp.NET MVC und WebMatrix. Der Entwickler bzw. das Team hat die Freiheit, das zu wählen was ihm bzw. ihnen am Besten zusagt. Wenn dies WebMatrix ist, ist es richtig, wenn es MVC ist auch. Ich will mit diesem Posting niemanden mitteilen, WebMatrix oder klassisches Asp.net sei von gestern oder für Anfänger - ich will jenen, die sich mit Asp.Net MVC beschäftigen einen Einstieg geben.

Ad Silverlight, WPF vs. Asp.NET MVC: hier gilt zu beachten das eine Datenbindung aus diversen Gründen nicht so einfach zu realisieren ist; die Technologien sind grundsätzlich anders (klassisches HTML vs. einer Client-Technologie). Mit SL, WPF kann man den View schnell mit Events über veränderte Daten informieren. In Asp.NET MVC wäre dies nur mit erheblichen Mehraufwand, welcher sich vermutlich nicht lohnt zu gehen, möglich.

Wie bereits oben gesagt: dieser Artikel gilt nicht als Angriff auf das klassische Asp.NET oder WebMatrix - sondern es ist für jene Personen die sich mit MVC beschäftigen wollen. Wir haben in der .NET Welt den Vorteil viele Techniken einsetzen zu können - welches Tool das richtige ist hängt im Endeffekt nicht von der "Glaubensrichtung" ab, sondern von den Fähigkeiten der Entwickler im Team.

Mario Meir-Huber Austria

>

22.03.2011 11:00:34 #

Die Frage bei MVC und warum lässt sich nicht nur bezüglich der Testbarkeit mit einem lauten "ja bitte" beantworten, sondern vor allem aufgrund seiner architektonischen Klarheit. Views zeigen nur an, wird etwas falsch dargestellt, etwas falsch formattiert, noch eine Design Anpassung da und dort:ein Blick in die View und ein paar Änderungen und das wars. Soll das (View) Model um zusätzliche Werte bereichert werden - das macht der Controller. Ich will jetzt nicht weiter langweilen, ihr wisst wie es weiter geht Smile

Weitere Argumente für Asp.Net MVC: Ajax - da brauche ich wohl nur "UpdatePanel" erwähnen und sauberes und schlankes Markup.

Zu "wenn einmal ein Button Event im View auscodiert wird, ist der der Entwickler kein schlechter Mensch" von Hannes oben: Broken Windows überziehen schnell den gesamten Code Smile

Christoph Walcher Austria

>

22.03.2011 11:20:34 #

Das Argument der Testbarkeit ist meiner Meinung nach nur ein eingeschränkt wirksames PRO für Asp.Net MVC. Wie Hannes schon geschrieben hat, glaube auch ich, dass 95% der Entwickler den Begriff Unit-Testing nur von Blogs und Foren kennen, aber noch nicht selbst was damit gemacht haben.

Viel wichtiger beim Asp.Net MVC finde ich allerdings, dass man nach der anfänglichen Lernkurve für Umsteiger von Asp.Net wirklich Spaß am entwickeln hat, weil man sehr schnell vorankommt. Bei Asp.Net habe ich mich immer wieder geärgert warum das HTML-Markup dieses oder jenes beinhaltet, was ich eigentlich nicht wollte (Stichwort "disabled"-Attribut). Ich denke, dass es hier noch ein paar Jahre dauern wird, bis die "konservativen" Enwickler diese Vorteile erkennnen und wechseln.

Mir gefällt immer noch der Vergleich zwischen Asp.Net und Asp.Net MVC - fahren Sie einen Van oder lieber ein Naked-Bike...

Daniel Lang Austria

>

22.03.2011 12:01:16 #

Es gibt im übrigen auch noch einige weitere Vorteile: So ist MVC stark auf ReST getrimmt. Mit den verschiedenen Optionen hinsichtlich ReST Services ist MVC auch stark in diesem Bereich unterwegs; Asp.NET MVC hat per default sehr gute ReST-Möglichkeiten. Zusätzlich kommt dann noch AutoReST hinzu, welches ich jedem empfehlen kann sich anzusehen.

Erst vor kurzem hatte ich ein Consulting-Projekt wo die ganze Business Logik der Anwendung in einer (!!!) Quellcodedatei lag - 16.000 Zeilen lang! Das war im übrigen eine klassische Asp.NET Anwendung. Wenn man Patterns ignoriert kommt man zu solchen Ergebnissen. Mit MVC ist man an eine saubere Architektur gebunden, somit kann sowas nicht so leicht passieren. Außer man setzt auf nicht skalierbare Anwendungen ;)

Mario Meir-Huber Austria

>

22.03.2011 12:52:36 #

Also REST und MVC haben soviel gemein wie Traktor und Getreide.

Ich habe auch nicht den geringsten Hang MVC religös für und wider zu diskutieren. Es ist mir im Grunde total egal ob jemand mit oder ohne Code schreibt.

Und ja ich habe die Erfahrung (in 25 Jahren Softwareentwicklung) gemacht das 95% aller Entwickler (und deren Entscheider) keine automatisierten Tests machen und auch nicht wollen. Das ist eine sogenannte Lebensrealität (die 95% sind eine willkürlich Zahl).
Den Entwicklern zu sagen, wenn Ihr nicht saubere Patterns oder TDD einsetzt dann seit Ihr sowieso das allerletzte ist nicht hilfreich. Es gibt Kundengruppen die brauchen das, es ist nützlich und steigert die Qualität. Die Majorität aber eben nicht (ich glaube keine einzige Iphone App hat mal einen automatisierten Test gesehen).

Genau in diese Stossrichtung geht das Argument "saubere Architektur". Architektur ist vorhanden oder nicht (aber nicht sauber oder unsauber). Ein Architekt setzt sich mit den Gegenheiten auseinander und plant eine Lösung unter berücksichtigung vieler Aspekte. MVC macht keine Architektur. Ich halte das für falsch zu behaupten MVC macht eine saubere Architektur. Architekten wenden Design Patterns an, setzen sich aber auch bewusst darüber hinweg. Um es klar zu sagen, ich bin kein Architekt sondern beziehe dieses Wissen aus Kontakten mit Leuten die z.B. für Daimler über 10 Jahre Softwarearchitektur gemacht haben.

Wenn nun aus den 95% nur 90% TDD verweigerer werden, ist das gut und hilft bessere Softare zu machen. Mein anliegen ist die restlichen 90% nicht zu verschrecken und sie als schlecht hinzustellen. So benennt Microsoft in Expression Blend sein MVVM Template auch nicht so, sondern nennt das Databound Application. Ganz im Sinne meiner vorigen Ausführungen.

Also für mich gilt: gute Software und guter Code kann völlig unabhängig vom Framework, Pattern oder Methodik geschrieben werden und das selbe gilt auch anders rum. (Das gleiche Argument höre ich auch gerne von C# Vb.NEt Diskussionen)

Am Ende müssen wir alle Geld verdienen und viele tun das mit der Technologie und vorgehensweise mit der für sie am einfachsten ist. Das ist im Web Umfeld z.B. leider PHP.

Die ursächliche Intution einen Kommentar zu verfassen, mehr Menschen dem Nutzen eines Design Patterns nahezubringen über die "Warum?" Frage sehe ich nicht aufgegriffen.

Hannes Preishuber Germany

>

23.03.2011 01:01:33 #

Hannes,

Vielem von dem was du schreibst kann ich nur zustimmen. Mein Eindruck ist auch, dass heute bereits sehr viel blindes over-architecturing betrieben wird. Da wird dann der Fowler als alleswissender Prophet hingestellt und plötzlich hat man für eine simple Todo-Listen Applikation eine 5-tier Architektur gewachsen im DDD, selbstverständlich mit DI-Containern, Repository-Pattern im DataAccesss und MVVM im Presentation Tier. Mit hunderten von Unit-Tests wird dann am eigens aufgesetzten CI-Server beim Nightly-Build sichergestellt, dass auch die Standardkonstruktoren von C# immer noch funktionieren und 2+5 noch immer 6 ist. So kommt bei "modernen" Softwareentwicklern heute der Stake-Holder nach 2 Wochen instensivem Scrum zu seiner Todo-Listen - Applikation und freut sich dass er jetzt seine Aufgaben verwalten kann...

ABER: Ganz anders verhält es sich mit automatisierten Tests!
Softwareentwickler bezeichnen sich heute ja gerne als Softwareingenieure, wobei dieser Begriff für die meisten wohl nicht zutreffend ist. "Ingerieure" aus anderen Branchen haben nämlich gemein, dass die von ihnen gelieferte Arbeit nahezu 100% fehlerfrei ist und erst die Kriterien Qualität und Korrektheit machen einen Techniker zu einem Ingenieur. Ganz anders verhält es sich bei uns SW-Entwicklern. Da wird ganz schamlos Software als "Release" verkauft, welche mit objektiven Maßstäben eigentlich noch nicht mal "Beta" sein dürfte. Die Anwender sind das aber schon gewöhnt und hinterfragen auch gar nicht weiter, wenn mehrmals in der Woche dann mit Updates und Bugfixes nachgeholfen werden muss. Wir - als gesamte Entwickler-Branche - haben einfach schon den Ruf keine wirkliche Qualität auf Anhieb zu liefern. Das schadet uns allen, und insbesondere denjenigen, die eben versuchen da nicht mit zu machen und ihre Werke vor dem Release ordentlich zu testen!

Ich persönlich finde es also absolut nicht ok, dass ein Großteil der Entwickler daran gewöhnt ist fehlerhafte Software abzuliefern und damit dem Ruf von uns allen schadet.

Microsoft macht es uns Entwicklern zu einfach schlechten Code zu produzieren und sollte viel restriktiver sein. MVC und MVVM sollten zum Standard erklärt werden und WebForm und WinForms als deprecated. Auf der Mac-Plattform hat man mit Obj-C und MVC zwar eine rießen Einstiegshürde, aber genau deshalb gilt Mac-Software nicht selten als stabiler und fehlerfreier als vieles von dem was auf unseren Windows-PCs rumschwirrt. Die Entwickler dort überlegen sich noch, ob eine Variable besser im stack oder im heap aufgehoben ist, während sich bei uns jeder zweite Softwareentwickler insgeheim fragt was denn eigentlich dieser "garbage collector" da macht...

Ein Grund warum mich dieses Thema ganz besonders nervt ist, dass uns regelmäßig Aufträge abhanden kommen, weil der unwissende Auftraggeber keinen Qualitätsunterschied zwischen einer RAD-Lösung mit Unify Team Developer und einer von uns testgetrieben mit WPF/MVVM entwickelten Software ausmachen kann... vielleicht aber einfach nur ein verkaufsstrategisches Problem von mir...

Daniel Lang Austria

>

23.03.2011 08:23:23 #

Nun, ich kann der Argumentation von Hannes gut folgen: nur, dass ich MVC verwende, macht die Software nicht besser. Ist eine gute Architektur aufgesetzt, ist es völlig egal, ob ich mein Ziel mit WebForms oder MVC erreiche bzw. umsetze. MVC ist für mich in erster Linie interessant, da es mich in eine bestimmte Form "zwingt". Aussagen, wie "WebForms hat alles immer anders als erwartet gerendert" (-> disabled, @Daniel) halte ich schlichtweg für falsch.
Ich kenne eine Reihe von Entwicklern, die sich früh von den Standard-ASP.NET-Controls verabschiedet haben und ganz dem Motto "back to the rules" sich auf die einfachen Lösungswege zurückbesonnen haben. Hier treffen wir uns dann gewissermaßen bei ASP.NET MVC wieder - vieles ist low level aber stark strukturiert.
Auch kann ich Hannes Aussage verstehen, dass zu viel Hype um TDD etc. gemacht wird. Das Tagesgeschäft bestimmt maßgeblich die Ausrichtung, die Kundenanforderung bestimmt die Zielrichtung - TDD, da wo es Sinn ergibt. Es gab vor einigen Wochen mal eine Diskussion von Thomas Bandt, der die Frage in den Raum stellte, ob es denn sinnvoll ist, für jedes Winzigprojekt vorneweg erst tausend Tests zu schreiben, oder ob man in bestimmten Fällen nicht lieber darauf verzichten sollte. Diese Diskussion hat deutlich die Problematik aufgezeigt, dass es gar nicht so vorteilhaft ist, wenn man mit aller Gewalt bestimmten Strukturen folgen will/muss, nur weil es gerade hype ist. Ich denke, aus diesem Alter ist man raus.
Ich erinnere mich noch gut daran, als ASP.NET auf den Markt kam - alle waren begeistert, haben ASP.NET gegenüber der bisherigen ASP-Entwicklung mit VBScript zum Maß aller Dinge erklärt. Und nun gehören WebForms abgeschafft? Das kann ja wohl nur ein Scherz sein.
Mit WebForms haben sich alle gefreut: kein Inlinecode mehr, alles schön im CodeBehinde, alles in Klassen gekapselt... Heute: toll Razor, es lebe der InlineCode... Na, ich weiß nicht.
Ich weiß nicht wie lange es schon her ist (ca. 8? Jahre), als Hannes in Bremen beim Usergrouptreffen gesagt hatte: "ja es wird wieder zurück zum Inlinecode gehen" - ich fand es damals schon seltsam, warum jetzt auf einmal wieder zurück zum Inlinecoding...
Ich würde es begrüßen, wenn wir in der ASP.NET Entwicklung da ankommen, wo wir mit XAML angekommen sind - das wäre eine feine Sache.
Dennoch, ASP.NET MVC hat sein eigenes Anwendungsfeld und damit gut seine Berechtigung. Solch einführende Beiträge, wie dieser, sind immer hilfreich für all jene, die sich mit der Thematik auseinandersetzen wollen oder müssen - doch verkommt es deswegen nicht gleich zum Heiligtum oder zum Maß aller Dinge, das sollte man sich nicht anmaßen.

Gruß
Rene

Rene Drescher-Hackel Germany

>

23.03.2011 10:16:29 #

So, jeder der sich durch den Beitrag angegriffen gefühlt haben mag: Ich habe immer betont (auch in den Kommentaren) das jeder das verwenden soll das für IHN am Besten ist. Für mich ist es eben MVC, für Hannes vermutlich klassisches ASP.NET. Nur weil es für mich besser ist, muss es für Hannes (oder andere) besser sein - im Endeffekt zählt, was der Entwickler/Architekt mit dem "Tool" macht. Das ist klar unabhängig vom Framework. Auch habe ich nie klassische Asp.NET

Die Diskussion läuft imho in die falsche Richtung, da es hier einige sehr emotionell betrachten @Hannes. Ich greife weder Dich persönlich noch jemanden, der nicht Asp.NET MVC verwendet, an. Dies ist "nur" ein Tutorial für jene die eben MVC lernen möchten - da spricht doch nichts dagegen, oder? Und hinsichtlich dem "warum": Es ist für genau diejenigen besser, die es bevorzugen. Das Thema kann man jetzt religiös betrachten und wir könnten ewig für und wider bringen - doch wird man im Endeffekt auf beiden Seiten Vor- und Nachteile finden. Wichtig nocheinmal: wir haben die Möglichkeit zu wählen und das ist gut so.

Zu Testing: Ich persönlich finde es als verantwortungslos, Software nicht zu testen.

Hinsichtlich Over-Architecturing: klar werden heute mit DDD uä viele Schichten eingezogen - ob das für Mini-Anwendungen Sinn macht sei dahingestellt. Einen sehr interessanten Ansatz bietet CQRS für große "Architekturen" (CQRS ist ein Anti-Pattern im allgemeinen). Kann dies jedem empfehlen anzusehen. In vielen Fällen kommt man jedoch an einer sauberen Schichtentrennung nicht vorbei, da es einfach die Wartbarkeit erhöht und wir ja nicht einmal schreiben, nach 2 Wochen wegwerfen-Produkte entwickeln.

Mario Meir-Huber Austria

>

23.03.2011 12:14:22 #

@Mario - ich für sehe niemanden der sich angegriffen fühlt. Ich über auch kein Kritik am Inhalt. Eine tolle sachliche Diskussion mit für mich wertvollen Input - Danke an alle. Schliesslich stellt sich mir durchaus die Frage ob wir uns für das was wir heute tun in 8 Jahren nicht schämen müssen.

Hannes Preishuber Germany

>

23.03.2011 12:27:15 #

Hallo Hannes,

danke das Du das auch so siehst. Eine sachliche Diskussion ist immer gut, ich habe jedoch die letzten Beiträge eher in die falsche Richtung laufen gesehen und daher alle darauf aufmerksam gemacht Smile. Es gibt in der IT schon zu viele Religionskriege (NoSQL vs. SQL, SOAP vs. ReST, Java vs. .NET, ...) da will ich eigentlich gar nicht mitmischen ;).

Mario Meir-Huber Austria

>

24.03.2011 15:48:51 #

Unittests bringen aus meiner Erfahrung nur etwas wenn Sie vom Management gefördert und gemessen werden. d.h ohne Buildserver braucht man auch keine Tests schreiben.

Daniel Siegl Austria

>

25.03.2011 23:17:54 #


@Mario ... ich bin mir sicher, JEDER testet seine Software. Die Frage ist, ob es jeder (automatisiert) mit Unit Tests tut. Und ob sie überhaupt überall Sinn machen. Wie Hannes schon gesagt hat, eine Smartphone-App wird wohl nur sehr selten Unit Tests über sich ergehen lassen müssen. Es lohnt sich einfach nicht für viele dieser Apps überhaupt Unit Tests zu schreiben weil durch das reguläre UI-Testing (um das man ja so oder so nicht umhin kommt) solch UI-lastiger Apps Fehler ohnehin schnell erkannt werden. Man kann es mit solchen Dingen einfach auch übertreiben. MVC nur um der (Unit-)Testbarkeit Willen ist sicher der falsche Ansatz.

Generell mag ich MVVM wie Hannes sehr gern, MVC aber auch nicht so sehr, im Falle von ASP.NET zumindest ... mich persönlich stört am meisten, dass man wieder in der "alten Zeit" landet und wieder Inline-Code in HTML pfropft. Für mich der größte Vorteil von klassichem ASP.NET - endlich kein HTML und Code-Mischmasch mehr.

Trotzdem hat man mit ASP.NET MVC unbestreitbare Vorteile wie mehr Kontrolle über den HTML-Output, einfacherer Einbau von URL Rewriting usw. ... weshalb ich schweren Herzens auch eher zu ASP.NET MVC tendiere bei neuen Projekten. Mit Razor wurde nun ja wenigstens eine wirklich gute Inline-Syntax eingeführt die mir den Wechsel docu um einiges leichter macht.

Bernhard König Austria

>

26.07.2011 09:02:30 #


Hallo zusammen,

was mir an dieser Diskusion gut gefällt ist das man auch mal ein paar kritische Stimmen hört.
Dazu gehört meiner Meinung nach auch der Mut dazu.
Stelle ich mich beim Thema TDD auf die Seite der Beführworter kann ich ja nichts falsch machen. Ich bin "IN HYPE und natürlich ENGENEER".
Stelle ich das Ganze in Frage habe ich schnell die Situation das alle abschätzig mit dem Finger auf mich zeigen.
Diese Erfahrung habe ich jedenfalls gemacht. Oh Mann ich habe den Fehler gemacht mich zu OUTEN das ich nicht jeden Schei... teste. Wie oben erwähnt. Ist nun 5 + 2 = 6 oder nicht?

Ich sehe es so. Muß ich eine Software für die Steuerung des neuen Spaceshuttles schreiben werde ich Diese testen und zwar mit allen zur Verfügung stehenden Mitteln.
Also auch mit TDD.
Ansonsten vielleicht nur die wirklich wichtigen Sachen oder halt gar nicht.
Ist das wirklich alles so aufregend?

Ich habe den Eindruck viele Themen werden zumindest im Microsoft Umfeld dazu mißbraucht sich zu profilieren.

Und das was für die Microsofties jetzt plötzlich alles so wichtig erscheint gibt es in JAVA und anderen Technologien schon lange. Auch das wurde oben schon erwähnt.


Gruß Horst









Horst Blechinger Germany

Pingbacks and trackbacks (1)+

Kommentar schreiben

  Country flag

biuquote
  • Kommentar
  • Live Vorschau
Loading

Datenschutzhinweis: Sie stimmen durch "Kommentar speichern" der Speicherung Ihrer Angaben durch Microsoft Österreich für die Beantwortung der Anfrage zu. Sie erhalten dadurch keine unerwünschten Werbezusendungen. Ihre Emailadresse wird auf Ihren Wunsch dazu verwendet Sie über neue Kommentare zu informieren.

Microsoft respektiert den Datenschutz. Datenschutz & Cookies

Datenschutz & Cookies · Nutzungsbedingungen · Impressum · Markenzeichen
© 2013 Microsoft. Alle Rechte vorbehalten · BlogEngine.NET 2.7.0.0 · Diese Website wird für Microsoft von atwork gehostet.
powered by atwork