Wer wie ich seit vielen Jahren mit relationalen Datenbanken zu tun hat, und sich nach langem Kampf endlich auch ein paar ausgefallenere SQL-Statements und Konstrukte merken kann, für den ist es sicherlich schwer vorstellbar, dass es da jenseits von SQL Server, Orcale, Access und der damit verbundenen Abfragesprache SQL noch etwas anderes gibt, und damit meine ich jetzt nicht überdimensionierte Karteikästen wie Filemaker.
Aber das gibt es, und nach ersten Gehversuchen erscheint mir das sogar sogar durchaus für das ein oder andere Projekt als Alternative denkbar (ich denke da insbesondere an den Mobile-Bereich).
Die Rede ist von "db4o", der "Database for Objects".
Um was geht's hier, und was ist so anders daran?
Am einfachsten lässt sich das anhand dieser entliehenen Grafik erklären:
(Copyright db4objects)
In oben erwähnten Datenbanken, den sogenannten "Relationalen Datenbank Management Systemen", speichert man seine Daten quasi immer inkompatibel zu seinen eigenen Geschäftsobjekten. Nehmen wir mal als Beispiel ein Objekt "Mitarbeiter". Der Mitarbeiter hat verschiedene Eigenschaften wie Personalnummer, Vorname, Nachname usw. In Code ausgedrückt sähe das zum Beispiel so aus:
public class Mitarbeiter
{
public Mitarbeiter() { }
public Mitarbeiter(int persoNummer)
{
PersonalNummer = persoNummer;
}
private int personalNummer;
public int PersonalNummer
{
get { return personalNummer; }
set { personalNummer = value; }
}
private string vorname;
public string Vorname
{
get { return vorname; }
set { vorname = value; }
}
private string nachname;
public string Nachname
{
get { return nachname; }
set { nachname = value; }
}
private string email;
public string Email
{
get { return email; }
set { email = value; }
}
}
An sich also recht unspektakulär für jeden der die ersten Klippen der objekt-orientierten Programmierung umschifft hat. Was machen wir aber nun mit diesem Objekt - wie bekommen wir da "Leben rein"? Richtig, wir erstellen eine neue Instanz für jeden neuen Mitarbeiter und befüllen deren Eigenschaften mit den entsprechenden Werten, wie Personalnummer ... Aber um diese Werte zu speichern, muss das Objekt als solches aufgelöst werden, damit es in die SQL-Server-Tabelle reinpasst. Diese kennt nämlich keine Objekte, sondern nur dumme, via SQL verknüpfbare, Felder.
Es braucht also einen "Mapper" der die Daten aus dem Objekt auf die entsprechende Tabelle "mapt". Im umgekehrten Weg aus der Datenbank ist es das Gleiche - wir holen uns die Daten aus der Tabelle via Select erstmal unstrukturiert ab, und füllen sie mit unserem eigenen Mapper in unser Objekt.
Das sieht dann zum Beispiel so aus:
public MitarbeiterListe GetMitarbeiter()
{
MitarbeiterListe mitarbeiter = new MitarbeiterListe();
using (SqlConnection connection = Helper.GetConnection)
{
using (SqlCommand cmd = new SqlCommand())
{
cmd.Connection = connection;
cmd.CommandText = "Select Personalnummer, Vorname, Nachname, Email From
Mitarbeiter Order By Nachname Asc";
connection.Open();
using (SqlDataReader reader = cmd.ExecuteReader())
{
Mitarbeiter m;
while (reader.Read())
{
m = new Mitarbeiter();
m.PersonalNummer = (int)reader[0];
m.Vorname = (string)reader[1];
m.Nachname = (string)reader[2];
m.Email = (string)reader[3];
mitarbeiter.Add(m);
}
}
}
}
return mitarbeiter;
}
Das ist alles ziemlich umständlich, und egal wie man es dreht - die Arbeit muss gemacht werden, ob nun automatisch generiert oder wie von mir immer noch bevorzugt von Hand geschrieben. Es ist auch keine Frage, dass sich diese Vorgehensweise bewährt hat - für eine Revolution reicht db4o (noch?) nicht, aber es reicht auf jeden Fall, um es sich einmal anzuschauen und es auszuprobieren.
Denn mit db4objects geht das eben gezeigte in einem Zweizeiler.
Wie? So:
Mitarbeiter who = new Mitarbeiter(1);
ObjectSet result = db.Get(who);
Hä? Ja genau ... wie und warum genau, ist der Dokumentation zu entnehmen, hier nur die Kurzfassung. db4objects macht genau das, was der Name verspricht: es speichert vollständige Objekte. Das heißt man kann seine selbst in .NET erstellten Objekte nehmen, und sie 1:1 in der Datenbank ablegen - absolut typsicher, und wirklich 1:1.
Abgefragt wird dann z.B. wie oben gezeigt, aber es geht natürlich auch etwas umfangreicher. Das Stichwort ist hier "Native Query".
Wer Lust hat, kann sich jetzt sein Visual Studio aufmachen, ein neues Konsolenprojekt starten und Folgendes reinkopieren - und staunen:
class Program
{
static void Main(string[] args)
{
ObjectContainer db = Db4o.OpenFile(@"D:\db4o\sample\db4o_sample\sample.yap");
Mitarbeiter max = new Mitarbeiter();
max.Email = "max@mustermann.de";
max.Nachname = "Mustermann";
max.Vorname = "Max";
max.PersonalNummer = 1;
db.Set(max);
Mitarbeiter who = new Mitarbeiter(1);
ObjectSet result = db.Get(who);
foreach (Mitarbeiter m in result)
{
Console.WriteLine(m.Nachname);
}
Console.Read();
}
}
Wer nun genau wie ich noch mehr Lust auf das Thema bekommen hat, findet weiterführende Informationen hier:
http://www.db4o.com/
Ich werde mich selbst wie oben bereits geschrieben sicher noch intensiver mit der Thematik auseinander setzen und es auch mal versuchen in der Praxis anzuwenden, d.h. weitere Erfahrungen werden hier folgen. Stay tuned
