© best_vector/Shutterstock.com
Windows Developer
Teil 3: Codierung Teil II - Businesslogik und Datenhaltung

Hinter den Kulissen

Auch Apps haben eine umfassende Businesslogik, um ihre Aufgaben zu erledigen. Sie greifen zudem auf vielfältige Datenbestände zurück. Im Gegensatz zu klassischen Applikationen liegen die Daten jedoch häufig nicht auf der lokalen Maschine oder auf dem Server im Nebenzimmer. Stattdessen werden sie von entfernten Cloud-Diensten bereitgestellt.

Veikko Krypczyk, Elena Bochkor


ArtikelserieTeil 1: Idee, Planung, PrototypTeil 2: Codierung Teil I – User Interface DesignTeil 3: Codierung Teil II – Businesslogik und DatenhaltungTeil 4: Zum Kunden und Geld verdienen: Deployment und Monetarisierung

Zwei Monate sind vergangen, seitdem wir unser Projekt begonnen haben. Das Ziel: Eine komplette App für die Universal Windows Platform (UWP) von der Idee bis zur Vermarktung im Store. Mit anderen Worten: In einem Vierteljahr soll es gelingen, eine erste Version einer marktfähigen App zu erstellen. Konkret geht es um die Entwicklung eines Word-Cloud-Generators.

Technisch befinden wir uns mittendrin: Die Oberfläche der App ist konzipiert und mithilfe des Designers von Visual Studio realisiert. Man kann die App auch schon starten und bekommt bereits ein Gefühl dafür, wie sie sich später im produktiven Betrieb anfühlen wird. Dennoch ist sie bisher lediglich eine leere Hülle ohne tatsächliche Funktionalität. Wie kommt diese in die App? Wir müssen die Businesslogik entwerfen und umsetzen. Dazu müssen wir uns Gedanken machen, welche Algorithmen im Hintergrund arbeiten. Ebenso zur Funktionalität gehören die Festlegungen zur Datenhaltung. Typische Fragen sind also: Wo speichern wir die Daten? Zum Beispiel in der Cloud, auf dem Server oder lokal im Anwendungsverzeichnis? Welches Format wählen wir? Zur Auswahl stehen die Optionen strukturiert in Tabellenform oder schemafrei. Die Antworten auf diese Fragen sind natürlich wieder individuell von der Art der App abhängig. Dennoch lohnt es sich, die Schrittfolge zu systematisieren und eine generelle Vorgehensweise abzuleiten.

Die App lernt denken

Eine App ist meist auf eine sehr spezielle Aufgabe konzentriert. Für ihren Erfolg ist es jedoch notwendig, dass diese Aufgabe exzellent gelöst wird. Es gilt der Grundsatz: Konzentration auf eine Aufgabe, wobei diese bestmöglich zu bearbeiten ist. Dies gilt auch für Apps der UWP. Sie können mobil und stationär verwendet werden. Grundsätzlich ist eine App kein Hexenwerk, d. h. die typische Dreischichtenarchitektur (Abb. 1) kann auch hier als Rahmenwerk angesetzt werden.

Abb. 1: Typische Dreischichtenarchitektur

Dazu ein paar grundsätzliche Bemerkungen: Eine Anwendung besteht üblicherweise aus dem User Interface (Presentation Layer), der Businessschicht (Service Layer) und der Datenzugriffsschicht (Data Access Layer). Insofern besteht bei einer UWP-App gegenüber einer klassischen Applikation noch kein Unterschied. Wir müssen drei Schichten und deren Verbindungen untereina...

Windows Developer
Teil 3: Codierung Teil II - Businesslogik und Datenhaltung

Hinter den Kulissen

Auch Apps haben eine umfassende Businesslogik, um ihre Aufgaben zu erledigen. Sie greifen zudem auf vielfältige Datenbestände zurück. Im Gegensatz zu klassischen Applikationen liegen die Daten jedoch häufig nicht auf der lokalen Maschine oder auf dem Server im Nebenzimmer. Stattdessen werden sie von entfernten Cloud-Diensten bereitgestellt.

Veikko Krypczyk, Elena Bochkor


ArtikelserieTeil 1: Idee, Planung, PrototypTeil 2: Codierung Teil I – User Interface DesignTeil 3: Codierung Teil II – Businesslogik und DatenhaltungTeil 4: Zum Kunden und Geld verdienen: Deployment und Monetarisierung

Zwei Monate sind vergangen, seitdem wir unser Projekt begonnen haben. Das Ziel: Eine komplette App für die Universal Windows Platform (UWP) von der Idee bis zur Vermarktung im Store. Mit anderen Worten: In einem Vierteljahr soll es gelingen, eine erste Version einer marktfähigen App zu erstellen. Konkret geht es um die Entwicklung eines Word-Cloud-Generators.

Technisch befinden wir uns mittendrin: Die Oberfläche der App ist konzipiert und mithilfe des Designers von Visual Studio realisiert. Man kann die App auch schon starten und bekommt bereits ein Gefühl dafür, wie sie sich später im produktiven Betrieb anfühlen wird. Dennoch ist sie bisher lediglich eine leere Hülle ohne tatsächliche Funktionalität. Wie kommt diese in die App? Wir müssen die Businesslogik entwerfen und umsetzen. Dazu müssen wir uns Gedanken machen, welche Algorithmen im Hintergrund arbeiten. Ebenso zur Funktionalität gehören die Festlegungen zur Datenhaltung. Typische Fragen sind also: Wo speichern wir die Daten? Zum Beispiel in der Cloud, auf dem Server oder lokal im Anwendungsverzeichnis? Welches Format wählen wir? Zur Auswahl stehen die Optionen strukturiert in Tabellenform oder schemafrei. Die Antworten auf diese Fragen sind natürlich wieder individuell von der Art der App abhängig. Dennoch lohnt es sich, die Schrittfolge zu systematisieren und eine generelle Vorgehensweise abzuleiten.

Die App lernt denken

Eine App ist meist auf eine sehr spezielle Aufgabe konzentriert. Für ihren Erfolg ist es jedoch notwendig, dass diese Aufgabe exzellent gelöst wird. Es gilt der Grundsatz: Konzentration auf eine Aufgabe, wobei diese bestmöglich zu bearbeiten ist. Dies gilt auch für Apps der UWP. Sie können mobil und stationär verwendet werden. Grundsätzlich ist eine App kein Hexenwerk, d. h. die typische Dreischichtenarchitektur (Abb. 1) kann auch hier als Rahmenwerk angesetzt werden.

Abb. 1: Typische Dreischichtenarchitektur

Dazu ein paar grundsätzliche Bemerkungen: Eine Anwendung besteht üblicherweise aus dem User Interface (Presentation Layer), der Businessschicht (Service Layer) und der Datenzugriffsschicht (Data Access Layer). Insofern besteht bei einer UWP-App gegenüber einer klassischen Applikation noch kein Unterschied. Wir müssen drei Schichten und deren Verbindungen untereina...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang