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
