Consulting

Die Atlas Informatik bietet Ihnen an, als Berater bei .NET-Projekten basierend auf WPF/Silverlight-Technologie zugezogen zu werden.

Was kann die Atlas Informatik für Sie tun?

Die Atlas Informatik hat sich in den letzten Jahren ein beträchtliches Know-How an WPF-Wissen aufgebaut. Jede WPF/Silverlight-Applikation, die gebaut werden soll, trifft wiederholt auf die selben Probleme. Wieso sollten Sie das Rad noch einmal neu erfinden und dafür viele Resourcen einsetzen?

Dazu ein paar Beispiele:

• WPF bietet dem Programmierer wenig Hilfe an, wenn er eine Model-View-ViewModel-Architektur bauen will. Diese ist aber nötig, um grössere Applikationen zuverlässig bauen und warten zu können. Wir haben eine Methodik entwickelt, die dies möglich macht. Der Umfang dieser Massnahmen würde jedoch diesen Text sprengen.
  
  
• WPF hat nur eine rudimentäre Unterstützung für die Datenvalidierung (Gültigkeitsprüfung). Eine Validierung über mehrere Eingabefelder hinweg ist nur mit einigem Programmieraufwand machbar. Die in WPF eingebauten Validierungsmittel sind auf die UI-Schicht beschränkt und daher am falschen Ort lokalisiert. Die Validierung gehört in die Model-Schicht, ev. zusammen mit einer Business-Rules-Engine. Wir haben ein Schema dafür entwickelt.
  
  
• Mehrsprachigkeit wird nur an vereinzelten Orten im UI unterstützt. Treten beispielsweise Ausnahmen auf, sind diese ev. nicht in der Sprache des Benutzers. Die Atlas Informatik verfügt über ein Konzept zur kompletten Sprachanpassung inklusive der Daten in der Datenbank.
  
  
• Korrektes DataBinding stellt eine Herausforderung dar. Visual Studio gibt leider fast keine Rückmeldungen, wenn ein Binding falsch geschrieben wurde. Es kann so passieren, dass Bindungsfehler erst nach der Auslieferung des Produktes bemerkt werden. Wir haben ein Verfahren entwickelt, welches dies bereits zur Designzeit anzeigt und eine Korrektur verlangt.
  
  
• WPF hat die Seltsamkeit, dass Fensteraktualisierungen während dem Verarbeiten von gedrückten Buttons auf später verschoben werden, vermutlich aus Effizienzgründen. Dies verunmöglicht laufende Statusanzeigen und Statusbalken. Wir haben das Problem so gelöst, dass sich der Programmierer nicht darum kümmern muss, aber ohne dass die Programmierung oder das Debuggen dadurch komplizierter wird (kein weiterer Thread), oder der Benutzer mit der Maus/Tastatur Manipulationen vornehmen kann (Folge einer oberflächlichen 'DoEvents()'-"Lösung").
  
  
• Mutationen an Objekten, die sich in einer ObservableCollection befinden, sind für den Besitzer der Collection nicht bemerkbar. Der Programmierer muss aufwändig an jedem einzelnen Objekt Eventhandler an- und abhängen. Wir haben eine Lösung dafür.
  
  
• Das Protokollieren aller Eingaben des Benutzers erleichtert das Nachvollziehen und Finden von Bugs enorm. Dies ist jedoch gar nicht so simpel zu erreichen. Wir wissen wie's geht.
  
  
• Es gibt in WPF keine einfache Möglichkeit, die Konfigurationdatei einer WPF-Applikation vor Manipulation und Spionage zu schützen. Viele Applikationen arbeiten daher mit einer offenen Datei. Da in dieser Datei auch häufig Verbindungsdaten zur Datenbank gespeichert sind, könnte ein gewiefter Benutzer ohne grossen Aufwand direkt in die Datenbank hineinschauen und sogar Manipulationen vornehmen. Wir haben dieses Problem gelöst.
  
  
• WPF neigt zu ständig zunehmendem Speicherverbrauch (Memory-Leaks), wenn man unbedacht programmiert. Wir wissen, wie man dies detektieren und vermeiden kann.