Laissez-moi vous expliquer avec un exemple. Supposons que votre sont la mise en œuvre d'une application à l'aide d'un classique SQL approche. Vous ouvrez les jeux d'enregistrements, de modifier des données et de la commettre.
Le Pseudo-code:
trx = connection.CreateTransaction();
query = connection.CreateQuery("Select * from Employee where id = empid");
resultset = query.Run();
resultset.SetValue("Address_Street", "Bahnhofstrasse");
resultset.SetValue("Address_City", "Zürich");
trx.Commit();
Avec NHibernate il ressemblerait à quelque chose comme ceci:
emp = session.Get<Employee>(empid);
// persistence ignorant 'logic'
emp.Address.Street = "Bahnhofstrasse";
emp.Address.City = "Zürich";
session.Commit();
L'Ignorance de la persistance signifie que la logique d'entreprise lui-même ne sait pas à propos de la persistance. Ou en d'autres termes, la persévérance est séparée de la logique. Cela le rend beaucoup plus réutilisable.
Déplacer la 'logique' de réutilisables méthode:
void MoveToZuerichBahnhofstrasse(Employee emp)
{
// doesn't have anything to do with persistence
emp.Address.Street = "Bahnhofstrasse";
emp.Address.City = "Zürich";
}
Essayez d'écrire une telle méthode à l'aide de jeux de résultats et vous savez ce que l'ignorance de la persistance est.
Si vous n'êtes pas convaincu, voir comment une simple unité de test, car il n'y a pas toutes les dépendances liées à la persistance des trucs:
Employee emp = new Employee();
MovingService.MoveToZuerichBahnhofstreasse(emp);
Assert.AreEqual("Bahnhofstrasse", emp.Address.Street);
Assert.AreEqual("Zürich", emp.Address.City);
DDD est quelque chose de différent. Il vous construisez votre domaine premier modèle (modèle de classe) et de créer la base de données de conception selon elle. Avec NH c'est très simple, parce que - grâce à l'ignorance de la persistance - vous pouvez écrire et de l'unité de tester le modèle et la logique avant d'avoir un (définitive) modèle de base de données.
Test: Nous testons les mappages par la création d'une instance de l'entité, de le stocker dans la base de données, le récupérer et de le comparer. Ceci est fait automatiquement avec beaucoup de réflexion. Mais vous n'avez pas besoin d'aller si loin. la plupart des erreurs typiques afficher lorsque vous tentez de stocker une entité.
On pourrait faire la même avec des requêtes. Des requêtes complexes méritent un test. C'est plus intéressant si la requête est compilé à tous. Vous n'avez même pas besoin de données pour cela.
Pour la base de données de tests d'intégration, nous sommes en utilisant Sqlite. C'est assez rapide. NH produit de la base de données en mémoire à la volée à l'aide de SchemaExport (avant chaque test).
