Tool Lagerverwaltung (Teil 4) Datenbank und Schnittstelle

Bisher hatte ich nur erwähnt, dass als dritte Schicht die Datenbank abbildet. Klingt etwas übertrieben, macht aber einen deutlichen Performance unterschied gegenüber der Verwendung von Text Dateien in CSV Format.

Benötigt

Visual Studio 2022 oder anderen Compiler
.NET 6.0
Codexzier's Application Framework
GitHub
SQLite
MS SQL oder PostgreSQL (nicht zwingend für den weiteren Verlauf)

Einbinden

Das Einbinden einer Datenbank soll so entkoppelt sein, dass die Datenbank Auswechselbar sein soll. Spricht, entweder soll SQLite für den Lokalen Einsatz verwendbar sein oder eine Externe Datenbank auf einem anderen Server.

Kein OR-Mapper

Man könnte an der stelle einen OR-Mapper verwenden, der für die Größe des Projektes auch völlig ausreicht. Aber ich will auf diesen Komfort verzichten und schreibe die SQL-Statement aus. Das Thema möchte ich für einen anderen Blogeintrag nutzen, in dem ein Umzug zum OR-Mapper beschrieben wird.

Tabellen

In den vorigen Post habe ich von den Einträgen immer von einer Sache gesprochen. Das liegt daran, dass in Zukunft zu speicherndem Inhalt offen ist und durch den Benutzer selbst definiert werden kann durch Vorlagen.

Nun soll die Haupttabelle nicht 'Sache' oder 'Thing' heißen, und 'Objekt' erst recht nicht. Passend ist 'Artikel' oder 'Item'. Fehlt also noch als Eigenschaft ID für die Eindeutigkeit des Datensatzes und 'Titel' soll in Kurzform beschreiben, was der Eintrag ist. Weitere Eigenschaften kommen später, denn jede weitere Eigenschaft muss sich aus dem Nutzerkontext ergeben.

 public class ArticleItem  
 {  
   public long Id { get; set; }  
   public string Title { get; set; } = "title";  
   public string Description { get; set; } = String.Empty;  
   public bool IsArchived { get; set; } = false;  
   public bool IsTemplate { get; set; }  
   IEnumerable<IArticleSubItem> ArticleSubItems { get; set; } = Array.Empty<IArticleSubItem>();  
 }

Schnittstellen definieren

Grundlegend werden mindestens drei Methoden benötigt. Speichern, Abrufen und aktualisieren. An der Stelle muss ich noch betonen, dass noch kein komplettes Konzept steht, weshalb die Schnittstelle rudimentär bleibt.

 public interface IDatabaseConnector  
 {  
   void CreateTable<TTable>();  
   void Insert(ArticleItem articleItem);  
   IEnumerable<ArticleItem> GetAll();  
   ArticleItem GetById(long id);  
   IArticleSubItem SubItem_GetById(long id);  
   void Update(ArticleItem articleItem);  
   void Update(IArticleSubItem subItem);  
 }

Nuget Pakete für SQLite

Hier reicht nur die Pakete zu installieren für SQLite. Die Installation MS SQL oder PostgreSql gehe ich nur ansatzweise an, um später zu zeigen, inwieweit ein Wechsel zu einer anderen Datenbank möglich ist. Deshalb werden bei den beiden Datenbank Technologien, dessen Nuget Pakete nicht installiert.

SQLite-net-standard 1.5.1
PostgreSQL
MS SQL

PoC - Proof of Concept

Der Wechsel zu einer anderen Datenbank. Die Funktionalitäten würde man zunächst in der Solution unter dem Projekt Komponenten hinterlegen. Das würde bedeuten, dass die Abhängigkeiten zu den drei Datenbanken in diesem Projekt liegen und später vorrausetzen, dass die Bibliotheken zu den anderen zwei immer gefordert werden, obwohl nur eine der möglichen Datenbank verwendet wird.

-> Option 1

Alles so lassen und später die Pakete rausnehmen, die man nicht braucht.

-> Option 2

Schnittstelle und Datenbanken in eigene Projekte verschieben. Über das Projekt ‚Componente' wird je nach Einstellung entschieden, welche Datenbank und Bibliotheken geladen werden soll.

Qual der Wahl

Bei einem Hobby Projekt reicht in der Regel die erste Option aus, solange man das für sich nur nutzen möchte. Die Anwendung hat keine großen Performance Ansprüche und wenn Probleme auftreten, kann man diese selbst schnell lösen.

Warum Option 2? Nicht wegen der Performance, sondern die Möglichkeit statt einer Lokalen Datenbank, auf eine zentrale Datenbank zu wechseln. Aber wenn diese Option nicht genutzt wird, sollten zumindest keine Probleme entstehen mit Referenzen, die nicht genutzt werden.

Erweiterung der Solution

Ein Projekt muss angelegt werden für die Datenobjekte und Schnittstelle, die ich hier 'SharedBasis'. Und für jede zu verwendeter Datenbank bekommt ein eigenes Projekt und erhält die Referenz zu dem Projekt 'SharedBasis'.

Was kommt in 'SharedBasis'

Hauptsächlich die Grunddaten Objekte und Schnittstellen, mehr sollte da nicht hineinkommen. Im Folgenden belasse ich mich auf die Schnittstelle für das Abrufen und Aktualisieren der Daten. Das Datenobjekt Artikel bekommt nur wesentliche Informationen, erst über dem ArticleSubItem wird der Umfang des Artikels ausgebaut. Darauf gehe ich in einen anderen Blogeintrag weiter darauf ein.

 public interface IArticleSubItem  
 {  
   long Id { get; set; }  
   long ArticleId { get; set; }  
 }

Für den Ausbau der zu definierenden 'SubItems', ist für den aktuellen Stand noch nicht erforderlich. Letzten Endes gehe ich nur auf Grundlagen ein, die aber soweit reichen müssen, damit sich für mich die weiteren Details erschließen.

Ein Projekt pro Datenbank

Die Verbindung zu den Datenbanken sind eigentlich bei allen sehr ähnlich und doch werden diese getrennt behandelt in jeweils einem Projekt. In jedes Datenbank Projekt muss einmal die Reference 'WarehouseManagement.SharedBasis' hinzugefügt werden. Für ein wenig Ordnung habe ich die Projekte in einen Solution Ordner 'Data' angelegt.

Interface einsetzen

Wie bereits im Projekt 'WarehouseManagement.DatabaseSQLite' zu sehen ist, habe ich die Klasse DatabaseConnector.cs angelegt, bzw. wurden die vorhandenen Klassen mit den Namen 'Class.cs' umbenannt und das Interface 'IDatabaseConnector' implementiert.

 public class DatabaseConnector : IDatabaseConnector  
 {  
   #region interface methods  
   public void CreateTable<TTable>()  
   {  
     this.Execute(db => db.CreateTable<TTable>());  
   }  
   public IEnumerable<ArticleItem> GetAll()  
   {  
     throw new NotImplementedException();  
   }  
   public ArticleItem GetById(long id)  
   {  
     throw new NotImplementedException();  
   }  
   public void Insert(ArticleItem articleItem)  
   {  
     throw new NotImplementedException();  
   }  
   public IArticleSubItem SubItem_GetById(long id)  
   {  
     throw new NotImplementedException();  
   }  
   public void Update(ArticleItem articleItem)  
   {  
     throw new NotImplementedException();  
   }  
   public void Update(IArticleSubItem subItem)  
   {  
     throw new NotImplementedException();  
   }  
   #endregion  
 }

Attribute einsetzen

Man kann den Namen der Datenbank Technologie in der Eigenschaft weglegen, erfordert jedoch, dass eine Instance vom 'DatabaseConnector' gestartet wird. Oder erweitert den Klassennamen zu 'DatabaseConnector' mit den Technologienamen. Beides ist nicht schön und deshalb passt die Verwendung von selbst erstellten Attributen, um dort den Technologienamen abzulegen.

 public class DatabaseConnectorNameAttribute : Attribute  
 {  
   public DatabaseConnectorNameAttribute(string name)  
   {  
     this.Name = name;  
   }  
   public string Name { get; }  
 }

So bleibt der Grundname und dennoch können die Klassen von ihrer Technologie unterschieden werden.

 [DatabaseConnectorName("SQLite")]  
 public class DatabaseConnector : IDatabaseConnector  
 {  
 ...  
 [DatabaseConnectorName("PostgreSQL")]  
 public class DatabaseConnector : IDatabaseConnector  
 {  
 ...  
 [DatabaseConnectorName("MS SQL")]  
 public class DatabaseConnector : IDatabaseConnector  
 {  
 ...

Test anlegen

Für das Erfassen der Datenbank Verbindungen (DatabaseConnector) wird im Projekt 'WarehouseManagement.Components' keine Reference der Datenbank Projekte hinzugefügt. Stattdessen soll das zur Laufzeit passieren und hierfür soll eine Klasse die Aufgabe übernehmen. Hier muss jedoch die 'WarehouseManagement.SharedBasis' Reference hinzugefügt werden, um später die Schnittstelle aus den Datenbank Projekten zu erkennen.

Der erste Unit Test soll die kompilierten DLLs aus den Datenbank Projekten einlesen. Beim ersten Mal und nach Änderungen der Datenprojekten, muss darauf geachtet werden, dass diese einen Aktuellen Bild hinterlegen. Oder einfach die gesamte Solution Inhalt neu kompilieren.

 [TestClass]  
 public class DatabaseConnectionTest  
 {  
   [TestMethod]  
   public void ReadDlls()  
   {  
     // arrange  
     // act  
     var result = DatabaseConnection.GetDatabaseConnectors();  
     // assert  
     Assert.IsNotNull(result);  
     Assert.AreEqual(3, result.Count());  
   }  
 }

DLL Dateien Namentlich filtern

Da alle Projektinhalte in einem Ordner landen, werden beim Abrufen der DLL-Dateinamen auch die mitgenommen, die keine Verbindung haben zu einer Datenbank.

Deshalb sollte hier der einfach nach den Projektnamen 'WarehouseManagement.Database' gefiltert werden.

Nun läuft der Test durch, ohne dass die DLLs gefunden wurden. Das liegt daran, dass für das Unit Test Projekt die DLLs nicht als Referenz genannt sind. Deshalb müssen diese noch rüber kopiert werden aus den Bin Order des jeweiligen Datenbank Projektes. Damit man über den Dateiexplorer nicht immer händisch rüber kopieren muss, kann dies über den Test Projekt Eigenschaften angeordnet werden mit den Build -> Output -> Post-build event und Xcopy

xcopy $(SolutionDir)WarehouseManagement.DatabaseSQLite\bin\Debug\net6.0\WarehouseManagement.DatabaseSQLite.dll $(SolutionDir)WarehouseManagement.Components.Test\bin\Debug\net6.0 /Y  
 xcopy $(SolutionDir)WarehouseManagement.DatabaseMsSQL\bin\Debug\net6.0\WarehouseManagement.DatabaseMsSQL.dll $(SolutionDir)WarehouseManagement.Components.Test\bin\Debug\net6.0 /Y  
 xcopy $(SolutionDir)WarehouseManagement.DatabasePostgreSQL\bin\Debug\net6.0\WarehouseManagement.DatabasePostgreSQL.dll $(SolutionDir)WarehouseManagement.Components.Test\bin\Debug\net6.0 /Y

Methode zu Ende ausschreiben

Nun sollte die Methode zum Einlesen der Datenbank Verbindungsstücke aus den DLLs gelesen werden können. Die Folgende Ausführung ist sehr kompakt geschrieben, welches durch Linq, Lamda-Ausdrücken und Reflection realisiert wird. Hier empfehle ich, die von euch gewohnte Ausschreibung des Codes zu verwenden. Dann fällt ein späterer Einblick in die einzelnen Codestellen leichter.

 public class DatabaseConnection  
 {  
   public static IEnumerable<string> GetDatabaseConnectors()  
   {  
     return Directory  
       .GetFiles(Environment.CurrentDirectory)  
       .Where(file => file.Contains("WarehouseManagement.Database"))  
       .Select(Assembly.LoadFrom)  
       .SelectMany(assembly => assembly.GetExportedTypes())  
       .Where(type => typeof(IDatabaseConnector).IsAssignableFrom(type))  
       .Select(type => type.Name);  
   }  
 }

Ansatz fertig

Und lasst euch in euerer Programmierung nicht reinreden, wenn eure Lösung funktioniert. Ein besser gibt's nicht. Sondern nur andere Lösungsformen.

Außerhalb des Themas 'Tool Lagerverwaltung' beschreibe ich den weiteren Ausbau der Datenbank Verbindungen in einen für sich geschlossenen Blogpost. In diesen ist der Ansatz gezeigt, wie sowas aufgebaut sein könnte.

Codestand: Database and interface

Übersicht

Teil 1 - Wiki anlegen in GitHub

Teil 2 - Neue Solution

Teil 3 - Noch ein Wiki anlegen

Teil 4 - Datenbank und Schnittstelle

Teil 5 - Konzept ausschreiben

Teil 6 - Umzug nach .NET MAUI

Links