C# Projekt Adressbuch – Einleitung

Wo fange ich an? In C# möchte ich mich einarbeiten. Ein richtiges Projekt soll es werden. Eine typische Windowsanwendung soll es sein, wenn es fertig ist. Was taugt hier als Einstieg, sich mit C# und Hochsprache im Allgemeinen vertraut zu werden, Erfahrungen zu sammeln und nachher eine Anwendung zu bekommen, die vielleicht nicht nur mir hilft? Gerne was sinnvolles. Nun ja, die Überschrift hat es verraten: Ein Adressbuch soll her. Ja, da gibt es bestimmt reichlich freie Lösungen und auch weniger freie in bestehenden Anwendungen. Nicht zuletzt das Windows-eigene Adressbuch aka Kontakte. Ich möchte nur nicht so eine funky fancy Windows-App, ich möchte das, was man noch Programm oder Anwendung nennt. Scheiße aussehen soll und muss sie natürlich deshalb nicht.

Wie beginnt man also? Ich für meinen Teil habe mir zuerst einmal Gedanken gemacht, was mein Programm denn können soll, abgesehen davon, einen Mehrwert zu liefern. Also habe ich mich hingesetzt, und vor geraumer Zeit bereits mit einem Anforderungskatalog begonnen. Hierzu habe ich mich der klassischen User Story bedient. Ich habe einfach alles in ein Worddokument getippt, was meine Anwendung später mal können soll. Bewusst so, als hätte ich keine Ahnung. Was anfangs nicht schwer war, weil ich bis auf ein bisschen Webentwicklung seit meiner Umschulung zum Fachinformatiker nichts an Berufserfahrung sammeln konnte. Warum denn also keine Webanwendung? Nun, weil mir das mit Hinblick auf späteren Nutzen nicht zielführend erscheint. Wenn andere Menschen meine Anwendung nutzen sollen, möchte ich das für jeden – unabhängig von der IT-Affinität – ermöglichen. Und da scheint mir eine typische Windowsanwendung am sinnvollsten.

In der Umschulung wurde Java behandelt. Warum also nicht Java? Weil! Ernsthaft: Bei meinem aktuellen Arbeitgeber (bin da im Support) wird C# als Entwicklungsumgebung eingesetzt. Und ob nun ein Nutzer eine bestimmte Version des .NET Frameworks oder die JRE installieren muss, ist für den unbedarften Nutzer egal. Zielgruppe also klar. Und die Einstiegshürden für C# sind dank grundlegender Java-Kenntnisse genauso niedrig, wie bei Java. Nebenbei ist SQL Server (Express) in C# besser integriert. Und wer sagt denn, dass ich nicht auch noch SQLite, mySQL/MariaDB und PostgreSQL unterstützen kann? Gehe ich also etwas näher auf meine Gedanken zur Datenbank ein.

Warum SQLite?


Warum nicht? Spaß! Hat schon einen Grund, dass ich das in Betracht ziehe. SQLite ist ein schlankes Datenbanksystem (DBS), nach allem was ich bisher gelesen habe. Und es eignet sich nach meinem ersten Eindruck wunderbar dazu, in der Anwendung mitgegeben zu werden. Weiterhin kommt SQLite in mobilen Anwendungen bevorzugt zum Einsatz. Das hat dann zwei Vorteile: Der Ottonutzer kann direkt nach Installation meines Adressbuchs loslegen und hat eine echte Datenbank im Hintergrund laufen. Da eine SQLite Datenbank aus nur einer einzigen Datei besteht, ist diese als einzelnes Element einfach zu sichern. Sollte es soweit erfolgreich verlaufen, böte sich weiterhin an, die Datenbank direkt zwischen Desktop und Smartphone zu synchronisieren. Da müsste dann nichts konvertiert werden. Ich kratze da erst an der Oberfläche. Daher sind das meine ersten Gedanken, die es mit Nahrung zu füttern gilt. SQL Server lässt sich, wenn ich nicht irre, einer Anwendung ebenfalls als Core-Variante mitgeben. To Do hier noch: Was ist performanter? Was bringt weniger Overhead – also Ballast im Installationspaket – mit? Wobei ich grob die Vermutung habe, dass sich bei einem Adressbuch vermutlich schon die halbe Facebooknutzerschaft eintragen müsste, um hier konkrete Vor- bzw. Nachteile spürbar werden zu lassen. Wenn ich an meine Kontaktliste auf meinem Smartphone denke, dann müsste ich zwar erst mal in Erfahrung bringen, ob da SQLite zum Einsatz kommt, nur spüre ich da keine Leistungseinbußen. Und ich horte Kontakte.

Warum mySQL/MariaDB?


Warum nicht? Noch ein Spaß! Eine Client-Server-Struktur ist doch optional ganz reizvoll. Nur betreibt wohl kaum ein Otto-Nutzer eine SQL Server (Express) Instanz. Ein halbwegs aktuelles NAS oder ein Raspberry Pi findet sich dagegen schon häufiger in Haushalten wieder. Und Stichword: NextCloud. Wobei ich mir hier vermutlich nicht die Mühe machen muss, noch eine Webanwendung für NextCloud zu bauen. Da wäre es wohl doch einfacher, vorhandene Ressourcen zu nutzen. Ist daher auf der SQL Liste am Ende einzuordnen. Da MariaDB lt. mariadb.com ein 1:1 Ersatz für mySQL sein kann (Fork von mySQL), warum nicht auch das in Betracht ziehen?

Warum PostgreSQL?

Wa… weil es kostenlos ist und eine Alternative zur Bindung an Microsoft mit SQL Server (Express). Außerdem hat PostgreSQL keine Limitierung bei der Datenbankgröße. Wenngleich man 10 GB einer Microsoft SQL Server Express Datenbank mit Kontakten auch erst mal füllen muss. Weiterhin soll die Performance Gerüchten zur Folge auch ziemlich gut sein. Oder das ist nur gefährliches Halbwissen von mir. Da kann ich für nichts garantieren. Fakt ist jedenfalls, die Sache mit der Lizenz wäre einfacher, wenn ich meine Anwendung mal monetarisieren wollen würde – was nicht der Plan ist. Und für die IT-Affinen unter den Nutzern findet sich ein angenehmes Datenbankmanagementsystem (DBMS) dafür. Hier verbloggt. Und einen ersten Eindruck habe ich mir in der Vergangenheit mit PHP auch schon mal verschaffen können. Mir hat’s gefallen. Daher eine Option. Soweit zu den DBS. Da gibt’s natürlich noch mehr, was ich nutzen könnte und möglicherweise auch versuchen werde, umzusetzen. Zum Beispiel, die…

Synchronisation

Im Abschnitt zu SQLite sprach ich es bereits an. Eine mobile Anwendung schließe ich nicht aus. Würde das Konzept jedenfalls verfeinern. Vorteil: Wenn ich es richtig aufziehe, wäre man nicht auf Google angewiesen. eiDevices besitze ich keine, und wenn sich kein Sponsor findet, wird sich das auch nicht ändern. Und mit C# soll auch das möglich sein. Wobei ich tendenziell eher dafür bin, nicht irgendwas über eine Webview zu wrappen, sondern gleich vernünftig zu arbeiten, wäre es für diesen Entwicklungsschritt vermutlich was natives. Habe gehört, Java geht da. Huch! Synergien zu C#! Andernfalls ist da noch Go, was wohl verwendet werden kann. Aber man soll nicht zu viel wollen. Die Wahl zu haben und sich dessen bewusst zu sein, empfinde ich als Bonus.

Ja nun, wie stelle ich mir die Synchronisation im Detail vor? Synchronisation der SQLite-Datenbank wäre ein Weg. Ein anderer wäre über irgend einen Umweg möglich. Hier ist noch Einarbeitung in Bezug auf SQL allgemein notwendig, bevor ich da mehr sagen könnte.

Grob soll meine Synchronisation jedoch die Client-Server-Struktur abdecken. Mindestens also möchte ich ermöglichen, mehrere Geräte ohne Onlinezwang auf dem gleichen Stand zu halten. Bleibt auf den ersten Blick also nur Nutzern mit Raspberry Pi oder tauglichem NAS vorbehalten. Jaaa… nicht ganz. Nur weil eines meiner Ziele eine gewisse Unabhängigkeit von diversen großen IT-Konzernen ist, muss ich deshalb Google ja nicht aussperren, oder? Muss ja keiner nutzen, der es nicht möchte. Tracking kommt daher nicht infrage und schon jetzt ist für mich klar: Wer die Google-Synchronisation verwenden möchte, wird einen Hinweis erhalten, dass er die Kontakte von anderen auf die Googleserver hochlädt. Auf der anderen Seite würde diese Anbindung auch den einfachen (naja, muss sich erst noch herausstellen, wie einfach das für mich dann zu implementieren wird) Export der Google-Kontakte ermöglichen, wenn man sich von Google verabschieden möchte.

Dann gäbe es da natürlich noch andere Dienste und Möglichkeiten. Mir geistert im Kopf noch die Idee herum, irgendwann auch eine Synchronisation mit einer Fritz!Box zu implementieren. Priorität hierfür ist allerdings gaaaanz unten anzusiedeln.

Grafische Benutzeroberfläche

Oberflächlichkeit gehört eben dazu. Ist wohl letztlich eine subjektive Entscheidung, wie die Anwendung später aussehen soll. Eine Idee habe ich schon und ein wenig in Visual Studio Code Express ausprobiert, wie sich das anfühlt, mit XML eine Oberfläche zu bauen, die Daten von einer Hochsprache annimmt. Mir ging es dabei allerdings eher darum, das Konzept und die Funktion dahinter zu verstehen. Wie bekommt man die Daten aus den Eingabefeldern in den C#-Code, um ihn von dort in die Datenbank zu schubsen?

Zwischenfazit

Soviel zu meinen Ideen. Grob umgesetzt habe ich bisher eine Konsolenanwendung, die nicht von Anfang an wie Kraut und Rüben aussieht und (hoffentlich) nicht jeden erfahrenen Entwickler in Ohnmacht fallen lässt, wenn er den Code sieht. Ich hab da viel hin und her probiert. Mir fehlt da auch komplett die Erfahrung bei der objektorientierten Denke. Wie dem auch sei, bisher hat es Spaß gemacht und ich bin aktuell dran, mich mit dem Teil der Datenbankanbindung zu beschäftigen. Davor hab ich ein paar Versuche für das Design mit Windows Presentation Foundation (WPF) gewagt. Da hats dann entweder viel XML in Form von Microsofts Eigenkreation XAML (Extensible Application Markup Language), oder wahlweise C# Code. Geht beides. Letzteres ist nur mehr Aufwand, weil mehr Code. Bin mir da noch nicht sicher, was ich machen soll. Vermutlich einen Mix, wenn sich mit XAML meine Ansprüche an bestimmte dynamische Eigenschaften nicht realisieren lassen.

Werbung

Eine Antwort zu “C# Projekt Adressbuch – Einleitung

  1. Pingback: Projekttagebuch Addressbook – Prototyping | i can compute

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit deinem WordPress.com-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Diese Seite verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden..