Architektur
Als Abonnent haben Sie vollen Zugriff auf alle Artikel im Archiv.
Zum Download eines Artikels und/oder der zugehörigen Quelltexte, klicken Sie
den gewünschten Artikel einfach an.
(
dotnetpro 03/2012,
Seite 120)
Am Schluss steht „fertig“: In fünf Teilen entsteht in .NET für einen imaginären Kunden eine kleine Einkaufszettel-App für das iPhone. Die letzten Features sind Einträge abhaken, Einträge ausblenden und speichern.
(
dotnetpro 02/2012,
Seite 136)
Irgendwas ist doch immer. Kein Softwareprojekt läuft genau nach Plan. So auch bei der Entwicklung der Einkaufszettel-
Anwendung AppShoppen: Im Emulator läuft sie wunderbar, auf dem iPhone gelinde gesagt verbesserungsbedürftig.
(
dotnetpro 01/2012,
Seite 130)
Eine komplette Anwendung entsteht. Am Schluss des dritten Teils lässt sich ein voreingestellter Einkaufszettel abhaken.
Davor sind die Hürden Spinning, Touch.Unit und Flow-Design zu überwinden.
(
dotnetpro 12/2011,
Seite 135)
Anwendungsfälle sind ein sehr nützlicher Weg, Anforderungen zu erfassen. Ihre Stärke spielen sie in Softwareprojekten aus, mit denen definierte Geschäftsprozesse beim Kunden unterstützt werden. Wird Software jedoch für unterschiedlichste Arbeiten eingesetzt wie etwa eine Textverarbeitung, lassen sich Anwendungsfälle eleganter mithilfe von Personas identifizieren.
(
dotnetpro 12/2011,
Seite 128)
Je weniger die Businessschicht von ihrer Umgebung weiß, desto besser ist sie. Denn dann ist sie nur lose an andere
Schichten gekoppelt. Diese agnostische Grundausrichtung erleichtert das Anpassen an neue Bedingungen.
(
dotnetpro 12/2011,
Seite 126)
Geschäftsklassen benötigen oft unterschiedliche Basisfunktionalitäten. Prinzipiell wäre dafür Mehrfachvererbung von
Vorteil, was .NET jedoch nicht unterstützt. Mithilfe von Mixins lassen sich die Vorteile von Mehrfachvererbung nutzen,
ohne dass deren Nachteile in Kauf genommen werden müssen.
(
dotnetpro 12/2011,
Seite 120)
Toolinstallation folgt Anforderungserhebung: Langsam nimmt die Einkaufszettelanwendung Formen an.
Der Kunde kann am Ende des Artikels die Anwendung schon im Emulator testen.
(
dotnetpro 11/2011,
Seite 136)
Diese Artikelserie zeigt anhand einer schlanken Cloud-Lösung, wie Sie Stück für Stück eine Anwendung aufbauen.
Den Anfang macht eine Spike-Lösung zum Kennenlernen eines neuen API.
(
dotnetpro 10/2011,
Seite 130)
Ein paar Monate haben die Event-Based Components schon auf dem Buckel. In dotnetpro hat es zu dem Thema schon
einige Artikel gegeben und im Internet jede Menge Blogposts. Doch tun sich zu dieser Technologie viele Fragen auf.
dotnetpro hat sie zusammengestellt und Ralf Westphal gebeten, sie zu beantworten.
(
dotnetpro 10/2011,
Seite 120)
Einen Dialog aurufen? Wie einfach! Wer aber dafür bloß ShowDialog() verwendet, vermischt Oberfläche und
Anwendungslogik und erschwert das automatisierte Testen. Mit MVVM gelingt die Trennung.
Aber es erfordert Aufwand, diese Trennung auch bei höheren Anforderungen konsequent durchzuhalten.
(
dotnetpro 10/2011,
Seite 128)
In manchen Situationen wünscht man sich, man könnte Klassen erweitern, ohne sie selbst verändern zu müssen.
Genau das geht mit der Mixin-Technologie.
(
dotnetpro 09/2011,
Seite 132)
Verglichen mit dem Wasserfall-Modell ist das agile Scrum ein Schritt in die richtige Richtung. Scrum fügt sich
viel besser in die Besonderheiten der Softwareherstellung ein. Und doch sollten Sie Scrum nicht einsetzen, denn
es setzt auf eine falsche Maßgröße.
(
dotnetpro 09/2011,
Seite 130)
Das klassische OOP ist tot. Dieser Ruf geistert bereits seit längerer Zeit durch die Communities. Doch was tritt an seine Stelle? Eine Option bietet dasArchitekturmuster DCI (Data, Context, Interaction). Es lässt sich mithilfe von Mixins realisieren.
(
dotnetpro 08/2011,
Seite 132)
Rekursive Lösungen gelten als elegant – aber auch als Spiel mit dem Feuer. Nicht von ungefähr kommt der Merksatz
„Rekursiv geht’s meistens schief“. Mit der passenden Darstellung des Ablaufs und einer Übersetzung in Flow-Design verliert die Rekursion jedoch an Schrecken.
(
dotnetpro 07/2011,
Seite 137)
Die Windows Presentation Foundation ist wie keine andere Technologie für Anwendungsoberflächen als Plattform
für erweiterungsfähige Programme geeignet. Allerdings konkurrieren bei ihr verschiedene Möglichkeiten miteinander. Dieser Artikel stellt ein Modell vor, mit dem alles an seinen richtigen Platz kommt.
(
dotnetpro 06/2011,
Seite 124)
Wie wird aus Anforderungen Code, der den Kunden zufriedenstellt? Ganz sicher nicht durch eine unmittelbare
Übersetzung. Dazwischen liegen nämlich noch solche Dinge wie Planung und Architektur.
(
dotnetpro 05/2011,
Seite 134)
Wie kann ein Kunde einen kleinen Ausschnitt seiner Anwendung prüfen, wenn die Anwendung noch gar nicht existiert? Das Problem lösen Ingenieure anderer Branchen mit Prüfständen.
(
dotnetpro 04/2011,
Seite 132)
Wer Software in objektorientierterWeise entwirft, beginnt die Analyse von Anforderungen meist mit der Suche nach
Substantiven. Daraus werden Klassen, die bekommen Eigenschaften und auf die wird Funktionalität verteilt.
Dabei ist Software viel näher amTun: Die Zukunft gehört den Verben.
(
dotnetpro 03/2011,
Seite 128)
Diese Schnittstelle gibt es seit dem .NET Framework 1.0. Und doch gehört sie zu den Funktionalitäten, die am wenigsten verstanden sind und angewendet werden. Dabei kann der richtige Einsatz viel Code sparen beziehungsweise den Code lesbarer machen.
(
dotnetpro 02/2011,
Seite 136)
Event-Based Components sorgen für Entkopplung von Funktionalität. Paralleles Entwickeln wird damit möglich. Aber EBC
führen auch zu Problemen:Verdrahtungscode ist unübersichtlich. Die passenden Tools können hier weiterhelfen.
(
dotnetpro 01/2011,
Seite 136)
Event-Based Components portionieren Code in testbare Häppchen.Wer aus ihnen aber ein Programm zusammenstellen will, verliert sich schnell im Verdrahtungswirrwarr. Tools führen Sie sicher durch den Drahtdschungel.
(
dotnetpro 12/2010,
Seite 130)
Im letzten Teil der Trilogie kommt es zum Showdown: Komponentenwerkbänke aufbauen, Tracer Bullet schießen, Featurescheiben implementieren und Codeanalyse im Review.
(
dotnetpro 11/2010,
Seite 130)
Schritte fünf bis sieben: Spike Solutions helfen,Wissenslücken zu schließen. Die Identifizierung von Komponenten
bereitet die Arbeit für das Team vor, und Featureteams sorgen für klare Verantwortlichkeiten.
(
dotnetpro 10/2010,
Seite 126)
Anforderungen abholen und sofort mit der Implementierung beginnen:Wer Software so entwickelt, riskiert den
Absturz der Projekte. Richtiges Vorgehen in elf Schritten hilft, sicher an den Abgründen vorbeizulaufen.
(
dotnetpro 09/2010,
Seite 132)
Am Ende einer Fernsehserie mündet alles in das Gefühlstaumel-Happy-End. Wo Hollywood vorlegt, will dotnetpro nicht zurückstehen. Aus einer Brownfield-Anwendung wird Software, die nach den Prinzipien des Clean Code Developers aufgebaut ist.
(
dotnetpro 08/2010,
Seite 126)
Was haben ein Topmodel und ein Blockschaltbild gemein? Beide schauen toll aus. Während aber in dem einen noch
Intelligenz, Gefühl undWissen stecken können, bleibt das andere eine Sammlung von Farbflächen ohne ein Mehr
an Information. Schaltpläne mit Event-Based Components bieten hier wesentlich mehr Zusammenhänge.
(
dotnetpro 07/2010,
Seite 126)
Anonym ist in. Zumindest unter Komponenten. Denn wenn keine Komponente die andere kennt, können sie leicht
ausgetauscht werden. Damit sind sie testbar, wiederverwendbar und aggregierbar. Und der Theorie lässt Ralf Westphal
Praxis folgen: Die Beispiel-Anwendung dreht Wörter um, ganz so, als wären die Buchstaben unabhängig.
(
dotnetpro 06/2010,
Seite 132)
Wer Hardwareplatinen zusammenbastelt, hat es mit diskreten Bauteilen zu tun: Kondensatoren, Transistoren, ICs und
Widerstände.Warum gibt es solche Bauteile nicht auch in der Software? „Gibt es“, sagt RalfWestphal und führt Sie
ein in die Welt der Event-Based Components.
(
dotnetpro 05/2010,
Seite 124)
Würden Sie sich als Mensch mit Persönlichkeitsspaltung bezeichnen? Wenn ja, haben Sie die besten Voraussetzungen,
durchgängig sauberen Code zu schreiben. Denn Sie schlüpfen je nach Anforderung in die Rolle des Feature-Entwicklers oder die des Clean Coders. Für alle anderen gilt: Lernen, worauf Sie künftig achten müssen.
Diesmal am Beispiel einer verteilten Lesezeichenanwendung.
(
dotnetpro 05/2010,
Seite 130)
Architektonische Entscheidungen sind ohne die Berücksichtigung technologischer Rahmenbedingungen undenkbar, denn Technologie definiert das Fundament, auf dem sich Architektur bewegen kann. Dieser Artikel zeigt anhand des WCF-Erweiterungsmodells das Zusammenspiel zwischen Technologie und Architektur.
(
dotnetpro 04/2010,
Seite 133)
Dass eine einzige Installation einer Anwendung zugleich mehrere Benutzer bedienen soll, ist eine häufig geforderte
Funktion. Dafür ist jedoch eine korrekte Datentrennung notwendig. dotnetpro zeigt, wie Multimandantenfähigkeit
bereits auf Basis der Datenbank hergestellt werden kann.
(
dotnetpro 04/2010,
Seite 124)
Eben mal ein paar Objekte wegschreiben und per Schlüssel wiederholen: Lassen Sie in so einem Fall die relationale
Datenbankkiste nur ja im Keller stehen. Dafür gibt es Lösungen wie das Lounge Repository. Wie es entstanden ist
und wie es funktioniert? Bitte treten Sie ein, wir führen Sie durch die Lounge und erzählen ihre Entstehungsgeschichte.
(
dotnetpro 03/2010,
Seite 132)
Mit LightCore steht ein Microkernel zur Verfügung, der quasi nebenbei auch als Dependency-Injection-Container dient:
Er ist leichtgewichtig, kompakt und vor allem schnell – ohne dass man dabei Features vermissen würde.
(
dotnetpro 02/2010,
Seite 130)
Idealerweise sagt der Name einer Funktion, was sie tut oder was sie zurückgibt. Bei einem sogenannten Fluent
Interface wird das wesentlich weiter getrieben:Mehrere aneinander gekettete Methodenaufrufe formen einen Satz, der sowohl für Menschen als auch für den Compiler gut verständlich ist.
(
dotnetpro 01/2010,
Seite 124)
Wer mitreden will über automatisiertes Testen oder testorientiertes Entwickeln, muss es selbst ausprobieren.
dotnetpro-Autor Golo Roden hat sich dieser Übung unterzogen und kann nun mitreden.
Sein Beispiel gerät zu einem Lehrstück, wie testorientiertes Entwickeln in Angriff zu nehmen ist.
(
dotnetpro 12/2009,
Seite 124)
Schnittstellen gehören zu den wichtigsten Elementen der Softwarearchitektur, sind die Grundlage verteilter
Anwendungen und stehen am Anfang jeder Softwareentwicklung. Ihre Konzeption ist oft nicht einfach.
Dieser Artikel zeigt erste Schritte auf dem Weg, Ordnung in die Vielzahl der Möglichkeiten zu bringen.
(
dotnetpro 12/2009,
Seite 119)
Eine Abstraktionsschicht oberhalb der Implementierung: Alle Welt kann sie dringend brauchen. Damit könnten
Mitarbeiter der Fachabteilungen ihre Geschäftsregeln festlegen, Projektmanager die Anforderungen an die
Software definieren und Entwickler modellgetrieben entwickeln. Einige neuere OMG-Standards unterstützen genau
diese Abstraktionsschicht.
(
dotnetpro 12/2009,
Seite 110)
Nicht nur das reale Universum expandiert, sondern auch das Softwareuniversum. Nun hat es die Ebene der
Anwendungsarchitektur erreicht. Der Effekt: Architektur abstrahiert, immer mehr weg von konkreter Technik, hin zu echten logischen Konzepten.
(
dotnetpro 12/2009,
Seite 130)
Design by Contract erhält mit der Code-Contracts-Bibliothek einen festen Platz im .NET Framework 4.0. Der erste Teil
der Serie hat die Bestandteile und Konzepte von Design by Contract und Code Contracts grundlegend vorgestellt.
Dieser zweite Teil vertieft ausgewählte Aspekte, etwa die Vererbung von Verträgen, und erklärt die Unterschiede zu
Konzepten wie Test-Driven Design.
(
dotnetpro 11/2009,
Seite 130)
Eine bestehende monolithische Anwendung mit Unit-Tests nachzurüsten ist möglich, wenn auch kein Spaziergang.
Es besteht kein Grund, davor Angst zu haben. Ein kleines Programm zum Wortezählen hat gezeigt, wie
der Weg dorthin mit Integrationstests beginnt und über aufgetrennten Code führt. Das Ziel: Separate Komponenten
und Kontrakte – und schon sind Unit-Tests möglich.
(
dotnetpro 11/2009,
Seite 124)
Eigenschaften und Verhalten eines Codeelements mit einer Spezifikation explizit ausdrücken – das ist das Ziel von
Design by Contract. Das Konzept erlebt derzeit eine Renaissance, da es mit der Code-Contracts-Bibliothek
Einzug in das .NET Framework 4.0 hält. In einer zweiteiligen Serie erläutert dotnetpro Prinzipien, Technologie und
Anwendung von Design by Contract und Code Contracts.
(
dotnetpro 10/2009,
Seite 130)
Wer Software schreibt, sollte sie sofort auch selbst testen. Aber nicht irgendwie, sondern automatisiert mit Unit-Tests. Das ist keine wirklich neue Erkenntnis. Dennoch ist solches Vorgehen immer noch keine selbstverständliche Praxis. Da stellt sich die Frage: Warum nicht?
(
dotnetpro 09/2009,
Seite 130)
Wer seine Software als Komponenten entwickelt, hat beim Outsourcing die Nase vorn. Denn eine solide
Komponentenorientierung stellt alle Instrumente zur Verfügung, um Dienstleister so genau wie möglich zu beauftragen – damit das fertige Produkt so aussieht, wie es gedacht war, und sich Korrekturen minimieren.
(
dotnetpro 08/2009,
Seite 124)
Mit seinem Heckle-Service hat Christian Weyer eine Beispielanwendung für Windows Azure vorgestellt.
Ralf Westphal hat einen sehr ähnlichen Zwischenrufdienst mithilfe des Application Space konzipiert.
Nun werden die Clients für Referent und Teilnehmer implementiert.
(
dotnetpro 07/2009,
Seite 131)
Mit seinem Heckle-Service hat Christian Weyer eine Beispielanwendung für Windows Azure vorgestellt.
Ralf Westphal konzipiert hier einen sehr ähnlichen Zwischenrufdienst mithilfe des Application Space.
(
dotnetpro 07/2009,
Seite 124)
Es geht auch einfach. Komponenten über die Weiten des Internets miteinander kommunizieren zu lassen, muss nicht
schwierig sein. Das Baukastensystem Application Space vereinfacht vielschichtige Aufgaben.
(
dotnetpro 06/2009,
Seite 126)
Parallelverarbeitung können Sie auch anders implementieren als mit den üblichen Threads. Mit dem richtigen
Framework können Sie einfach Aufgaben für Dienste zur Ausführung „einplanen“, indem Sie ihnen Nachrichten
schicken. Die Concurrency and Coordination Runtime von Microsoft macht das möglich.
(
dotnetpro 05/2009,
Seite 120)
Mit Microsofts Concurrency Coordination Runtime lassen sich die Details des Multithreadings verbergen. Sequenzielle
Prozessschritte können Sie über Ports miteinander koppeln und dadurch parallelisierbar machen.
(
dotnetpro 05/2009,
Seite 129)
Wenn Softwarearchitektur über das reine Benennen von Schnittstellen und Komponenten hinausgeht, bedarf sie in
der Regel einiger Erläuterungen. Besser noch wäre ein Verfahren, mit dem sich eine Spezifikation gleich in
Programmcode umwandeln ließe. Dieser Artikel stellt eine Möglichkeit vor.
(
dotnetpro 04/2009,
Seite 124)
Langsam dämmert die Erkenntnis: Softwareentwicklung erfordert künftig einen neuen Ansatz: den der Parallelverarbeitung.
Klingt kompliziert, muss es aber nicht sein. Microsoft bietet einen Mechanismus, der das Entwickeln mit Threads abstrahiert.
Dazu gehört aber auch ein neuer Denkansatz seitens des Entwicklers.
(
dotnetpro 03/2009,
Seite 131)
Nach den ersten stürmischen Jahren ihres überschaubaren Lebens ist die Softwareentwicklung an einem Punkt angekommen,
an dem sie und ihre Protagonisten, die Entwickler, erst einmal innehalten und sich auf ein Wertesystem besinnen sollten.
Das meint zumindest dotnetpro-Philosoph Ralf Westphal und plädiert für den „Clean Code Developer“.
(
dotnetpro 03/2009,
Seite 124)
Das Konzept anspruchsbasierter digitaler Identitäten soll das Zusammenschalten von Zugangsdiensten auf Grundlage
von WS-Standards ermöglichen und den Zugangsmechanismus von Anwendung und Plattform entkoppeln.
Unter Windows war der Umgang damit bisher aufwendig und kompliziert. Die Plattform Geneva soll das ändern.
(
dotnetpro 02/2009,
Seite 128)
Parallelverarbeitung muss nicht schwierig sein. Zwar gilt es, bei der Koordinierung gleichzeitiger Aktivitäten mehr zu
bedenken als bei der üblichen synchronen sequenziellen Verarbeitung. Doch davon sollten Sie sich nicht
ins Bockshorn jagen lassen.
(
dotnetpro 01/2009,
Seite 128)
Die Zukunft der Softwareentwicklung liegt in der Parallelverarbeitung – daran führt früher oder später kein Weg vorbei.
Nur wenn das Potenzial jeder Anwendung in dieser Hinsicht erkannt und ausgeschöpft wird, kann sie von der
wachsenden Zahl an Prozessorkernen profitieren.
(
dotnetpro 12/2008,
Seite 130)
Wie erstellt man die Architektur für die Problemdomäne? Soll man sich hier besser auf die Daten oder auf die Prozesse konzentrieren? dotnetpro unternimmt einen Streifzug durch die verschiedenen Architekturmuster, von Transaction Script über Table Module und Active Record bis hin zu Domain Model. Besonders spannend: Manche Pattern sind in .NET und Visual Studio bereits fest eingebaut.
(
dotnetpro 12/2008,
Seite 126)
Das Migrieren einer bestehenden Anwendung kann eine spannende Sache sein – wenn Sie es richtig angehen. Im letzten Teil der Serie führen Sie die Erkenntnisse der Analyse der Anwendung zusammen und gießen sie zu einem neuen Innenleben für die Software. Dabei machen Sie diese gleich fit für künftige Anpassungen.
(
dotnetpro 11/2008,
Seite 118)
Den Legacy-Code einer bestehenden Anwendung zu durchforsten, um ihn für Erweiterungen oder eine neue .NETVersion
vorzubereiten: wie öde! Oder auch nicht – wenn Sie richtig dabei vorgehen und sich nicht in Codedetails
verzetteln. Mit den entsprechenden Werkzeugen ist es kein Problem, sich unbekanntem Code zu nähern.
(
dotnetpro 11/2008,
Seite 124)
Vereinbarungen innerhalb von Software sind ebenso relevant wie in der realen Welt. Nur gehört ihre Prüfung nicht
unbedingt zu den eigentlichen Aufgaben einer Software. AOP und das Framework PostSharp erlauben es, Software
logisch zu beweisen, ohne den Code der Geschäftslogik zu überfrachten.
(
dotnetpro 10/2008,
Seite 121)
Zwischen einem Flaschenzug und einer Computeranwendung besteht prinzipiell kein Unterschied. Beide setzen eine
Kette von synchronisierten Aktionen in Gang. Doch die Entwicklung der Hardware hin zu Mehrfachprozessoren
verlangt von der Softwareentwicklung eine neue Sicht auf Funktionen – nämlich eine asynchrone.
(
dotnetpro 10/2008,
Seite 114)
Datenstrukturen gehören zu den Grundpfeilern einer Anwendung. Sie bieten rudimentäre Gültigkeitsüberprüfungen
und Anwendungslogik. Unter dem Blickwinkel einer Gesamtarchitektur können sie jedoch problematisch sein,
wenn sie nur ungenügend mit anderen Aspekten abgestimmt sind. Metainformationen können das Problem lösen.
(
dotnetpro 09/2008,
Seite 123)
Architektur ist wesentlich mehr als das Aufbauen von Anwendungsschichten. Denn die Anforderungen sind für jede
Anwendung anders. Ralf Westphal, Content Manager der prio.conference 2008, erklärt im Interview, was die
Teilnehmer auf der Konferenz lernen können.
(
dotnetpro 09/2008,
Seite 124)
Legacy-Code muss nicht vom Mainframe stammen. Auch .NET-1.0-Code gilt bereits als „Vermächtnis“ von früher.
Gehen Sie bei einer Migration systematisch vor! Erarbeiten Sie sich die Problemdomäne. Entwerfen Sie den
SOLL-Zustand. Dann können Sie damit beginnen, alten Code Stück für Stück iterativ vom IST zum SOLL zu übertragen.
(
dotnetpro 08/2008,
Seite 129)
Seitdem das Model-View-Controller-Muster das Licht der Welt erblickt hat, haben sich die Ansätze zur Architektur von
Anwendungen weiterentwickelt. Um dieser Entwicklung gerecht zu werden, hat sich auch Model-View-Controller
angepasst. Seine jüngste Variante heißt Model-View-ViewModel.
(
dotnetpro 08/2008,
Seite 128)
Das Microsoft Add-in Framework (MAF) ist eine neue Möglichkeit, Anwendungen erweiterbar auf zubauen. Jörg Neumann wird das Framework auf der prio.conference 2008 vorstellen. dotnetpro sprach mit ihm, welche Vor- und Nachteile es bringt.
(
dotnetpro 07/2008,
Seite 141)
Scrum ist eine agile Technik, um Softwareprojekte abzuwickeln. Doch ist diese Managementmethode architektur - neutral? Oder erzwingt sie, Anwendungen in ganz bestimmter Architektur zu gestalten? Eine Diskussion.
(
dotnetpro 07/2008,
Seite 136)
Das Entwickeln von Software braucht mehr Regeln. Diese These vertritt dotnetpro-Autor Ralf Westphal und hat sich aufgemacht, diesen Missstand zu beheben. Denn wo Regeln herrschen, muss sich niemand den Kopf zerbrechen und hat Zeit und Muße für die anwendungsspezifischen Probleme.
(
dotnetpro 06/2008,
Seite 134)
Keine andere Problematik wird so kontrovers diskutiert wie die Trennung von Business Layer und Datenbank. Dabei
steht sie nur stellvertretend für ein Grundproblem der Informatik: Was ist Anwendungslogik und wie kann
sie auf die Bestandteile der Anwendung verteilt werden? Dieser Artikel gibt einen Überblick über die Details der
Fragestellung und zeigt Lösungsansätze.
(
dotnetpro 06/2008,
Seite 126)
Wie beim Hausbau braucht auch die Entwicklung von Software Konventionen, um Qualität erreichen zu können. Leider
gibt es derzeit davon zu wenig. Mehr Konventionen würden den Entwickler besser leiten, ihm Arbeit und Entscheidungen
abnehmen sowie mehr Zeit verschaffen, sich um das eigentliche Problemfeld der Software zu kümmern.
(
dotnetpro 04/2008,
Seite 142)
Die Programmierung unter Microsofts Office-Plattform wird vielfach unterbewertet und oft noch
mit einfacher VBA-Makroprogrammierung gleichgesetzt. Dabei ermöglicht sie mit eigenen
Architektur- und Entwurfsmustern die Entwicklung komplexer Geschäftsanwendungen für Office,
die durchaus den Ansprüchen an moderne Softwarearchitektur genügen.
(
dotnetpro 04/2008,
Seite 136)
Aus einer Handvoll Kundenanforderungen folgt die beste Architektur aller Zeiten. Ohne
Zweifel? Ohne Alternativen? Nein: Es gibt keine beste Architektur, denn diese hängt
nicht zuletzt vom zugrunde liegenden Wertesystem ab. Und auf den Geschmack kommt
es dann auch noch an.
(
dotnetpro 03/2008,
Seite 120)
Was man nicht messen kann, kann man auch nicht kontrollieren. Zur Steuerung gehört
aber noch der Plan, wie die Messwerte im Idealfall aussehen sollen. Ein Wertesystem also.
Dass es so etwas auch für die Architektur geben muss, dafür plädiert Ralf Westphal.
(
dotnetpro 03/2008,
Seite 135)
dnpPatViz, das Mustererkennungsprogramm für jegliche Art von textlich erfassbaren Mustern,
gedeiht. Nun fehlt für die nächste Version nur noch die grafische Anzeige von Mustern
in Form von Bögen. Dazu erhält die Software noch ein UserControl, das diese Aufgabe übernimmt
– und dazu noch einen FileAdapter für Midi-Daten.
(
dotnetpro 03/2008,
Seite 124)
Unter WPF führen oft mehrere Wege zum Ziel. Layoutanweisungen können im XAML-Code, im
Code einer Klasse oder in einem Stylesheet hinterlegt sein. Wer da nicht Ordnung hält, ver -
heddert sich leicht in unübersichtlichem Spaghetti-Code. Strukturieren Sie Ihre WPF-Anwendung
lieber so wie eine Prinzregententorte: schichtweise. Das erleichtert auch die Arbeit im Team.