Was ist Blueworker?

Bei Blueworker handelt es sich um ein Werkzeug das neben einer soliden Basisanwendung (Solution) auch nervige wiederkehrende Aufgaben weitestgehend automatisiert. Ein Beispiel dafür ist das Model. Die Namen und die Feldtypen müssen Sie festlegen, doch sowas lästiges wie SQL Scripte schreiben oder die Klassen erstellen ist die Aufgabe von Blueworker. Beim ViewModel ist es dasselbe, warum alles zweimal tippen wenn man das Model als Vorlage nutzen kann. Betonung liegt auf „kann“. Das besondere an Blueworker5 ist die extreme Flexibilität. Zwar hat Blueworker seine Pflegehoheiten die entsprechend gekennzeichnet sind. Was Sie jedoch nicht daran hindert die Gekennzeichneten Bereiche zu entfernen und die Pflegehoheit zu übernehmen. Auch sind Sie nicht gezwungen ein Model zu haben. Wenn Sie gerne ein anderes Model nutzen möchten steht Ihnen das frei.

Blueworker ist vergleichbar mit einer IDE

Statt die Solution und das Projekt in VisualStudio zu erstellen, lassen Sie Blueworker die Solution und die ersten Projekte erstellen und bekommen dabei eine bereits fertige Anwendung, die direkt gestartet werden kann.

Die Solution besteht (stand jetzt) aus den folgenden Projekten:

1.       Model (Klassenbibliothek)

2.       ViewModel (Klassenbibliothek)

3.       View (WPF)

4.       Support (Klassenbibliothek)

In einer späteren Version kommt noch Rest API und Android Studio hinzu. Und Ja, theoretisch ist Android Studio Entwicklung über die VisualStudio IDE möglich. Auch ohne Xamarin.

Blueworker5 würde später natürlich auch die Android View und den Rest Service betreuen.

Die Blueworker5 IDE

Die Blueworker5 IDE startet zuerst mit einem Erstellen Dialog. Entweder Sie öffnen eine Solution oder Sie erstellen und öffnen damit eine Neue Solution. So oder so kommen Sie in das Hauptmenü siehe unten. Dieses kann sich noch im Laufe der Zeit ein wenig ändern. Im groben und ganzen wird es jedoch so bleiben. Sie haben links Oben das Hauptmenü und Rechts die drei kleinen Hilfsknöpfe. Es empfiehlt sich nach dem Öffnen der IDE auch die Solution zu öffnen. Auch wenn dort erst einmal nicht drin gearbeitet wird. Man möchte ja hier und da mal Kompilieren und Testen. Im Beispiel heißt die Solution und damit auch die Anwendung Test3. Was aber noch nicht viel heißt in Bezug auf die finale Software. Dazu später mehr.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Die Grundeinstellungen der Solution

In den Grundeinstellungen können Sie festlegen ob Sie in einer DEV, Test oder Prod Umgebung entwickeln. Je nach dem verändert dies das Verhalten der Software. Starten Sie ihre Software als DEV ignoriert die Software jedes Berechtigungssystem. Sie sind dann quasi Super Admin. Folglich ist diese Version nicht für den Kunden bestimmt. Scripte können jedoch so eingestellt werden das Sie z.B. nur in DEV ausgeführt werden. So können Sie Scripte in DEV ausprobieren und haben trotzdem noch die Möglichkeit ein Produktiven Bug zu beheben. Da der Script in Prod nicht ausgeführt werden würde. So lässt sich natürlich jeder Teil des Codes auf die Umgebung festlegen. So können ganze Menüabschnitte auf z.B. DEV und vielleicht Test begrenzt werden. In Prod würde man diese Bereiche nicht nutzen können.

Wie Sie in der unteren Grafik sehen können ändern sich auch die Icons, Splashscreens, Bezeichnungen, Versionen und die FTP Release Verzeichnisse. Das verringert das Risiko eine Test Version versehentlich auf einem Prodserver auszurollen. Und auch das Risiko eine DEV Version zu Veröffentlichen geht gegen null. Da im Idealfall die DEV Version keine Release Verzeichnisse haben sollte.

Im Beispiel sind gut die drei Umgebungen zu sehen. Auch das Test gerade aktiviert ist. Heißt… würde man nun im VisualStudio eine Veröffentlichung durchführen, würde man auf die Testumgebung veröffentlichen. Und Scripte die nur für DEV sind würden ignoriert werden. Bereiche des Codes die für DEV ausgelegt sind, werden nicht aktiv sein.

Die Umgebung kann jederzeit gewechselt werden. Einfach auswählen und auf Aktivieren klicken.

 

Die unterschiedlichen Icons sollen dabei helfen früh zu erkennen, wenn man das Projekt aus der falschen Umgebung heraus gestartet hat.

 

 

 

 

 

 

 

 

 

Script Management

In Blueworker werden SQL Scripte über die Software beim Anwender ausgeführt. Sie müssen im Idealfall nur die Datenbank erstellen und die Anwendung mit der Datenbank verbinden. Alles andere übernehmen die in Blueworker erstellten Scripte. Dabei steht es Ihnen Frei wann Sie welchen Script verwenden. Bis Sie einen Script „Produktiv“ setzen. Doch dazu später mehr.

 

Nicht benötigte Fläche wird in Blueworker gerne mal für Tipps genutzt. Damit wird die eine oder andere Frage beantwortet, ohne die Dokumentation zu Rate zu ziehen.

Script Modies

Ein Script wird als „Planung“ erstellt. Planung ist unterhalb von allen anderen Modies. Da Sie die Umgebung mindestens in DEV ausführen, sind Scripte die in Planung sind niemals aktiv. Somit haben Sie zum einen die Möglichkeit die Umgebung jederzeit zu starten, ohne auf Ihre Scripte Rücksicht nehmen zu müssen. Und Sie können alles in den Planungs-Scripten jederzeit verändern. Anders sieht dies aus sobald Sie auf DEV wechseln. Dann gilt der Script bereits als gesperrt. Da das Risiko besteht, das ein oder mehrere Entwickler bereits den Script bei sich ausgeführt haben.

Das hindert Sie natürlich nicht daran den Script wieder in Planung zurück zu versetzen. Dort können Sie dann alle Änderungen machen und wieder in DEV schalten. Doch wieso dann nicht in DEV editieren? Das wechseln von DEV zu Planung sorgt dafür das ein Rollback Script erstellt wird. Ein Anwender, der bereits den Script ausgeführt hat würde dann den Rollback script nutzen um die Tabellen zu beseitigen und die richtigen Tabellen zu erstellen. Das sollte natürlich nur eine Ausnahme sein. Da es sehr ärgerlich ist, wenn jemand ständig sein Script in DEV veröffentlicht und dies wieder rückgängig macht. Aber die Möglichkeit wurde natürlich berücksichtigt.

Anders sieht das mit „Produktiv“ Scripte aus. Diese sind dauerhaft gesperrt. Einmal Prod immer Prod. Das hat den Hintergrund das der Kunde bereits mit den neuen Strukturen arbeiten könnte und dann käme ein Rollbackscript denkbar ungünstig.

Das Model

Um leichter mit der Datenbank zu kommunizieren gibt es das Model. Das Model ist eine Klassenstruktur die 1:1 der Datenbank entspricht. Mit der Möglichkeit zu Speichern und zu Laden.

Das ViewModel

Das ViewModel beinhaltet u.a. die Hauptfunktionalität des Programms. Alles was nicht mit Darstellung zu tun hat findet im ViewModel statt. Das ViewModel kann das Model konsumieren und Blueworker kann dies organisieren.

Hauptmenü Verwaltung

Auch das Projekt das zum Kunden geht hat ein Hauptmenü. Die WPF Variation lässt sich ebenfalls über Blueworker Konfigurieren und Pflegen. Alles inklusive des Erstellens neue Pages/Windows und der Berechtigung.

Und vieles mehr.