Каковы преимущества сохранения невежества?

Я новичок в мире DDD + TDD. Но я занимаюсь программированием почти 9 лет.

Может кто-то пожалуйста, объясните мне преимущества ignornace настойчивость? Типичное приложение nHibernate просто подталкивает зависимость между классом и базой данных к файлам сопоставления.

Если я изменяю файлы классов или базу данных, я должен изменить файлы сопоставления. Разве это не просто подталкивает зависимость, добавляя еще один уровень абстракции? На мой взгляд, до сих пор я не думаю, что это революционное. Но я не уверен, что мне что-то не хватает.

Наконец Как я могу проверить файлы сопоставления? Есть вероятность, что ошибки будут отображаться в файлах сопоставления, как я могу их протестировать?

Ответ 1

Позвольте мне объяснить это на примере. Предположим, что вы реализуете приложение, используя классический подход SQL. Вы открываете записи, изменяете данные и фиксируете их.

Псевдокод:

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();

С NHibernate он будет выглядеть примерно так:

emp = session.Get<Employee>(empid);

// persistence ignorant 'logic'
emp.Address.Street = "Bahnhofstrasse";
emp.Address.City = "Zürich";

session.Commit();

Сохранение Незнание означает, что сама бизнес-логика не знает о сохранении. Другими словами, персистентность отделена от логики. Это делает его гораздо более многоразовым.

Переместите "логику" на метод многократного использования:

void MoveToZuerichBahnhofstrasse(Employee emp)
{
  // doesn't have anything to do with persistence
  emp.Address.Street = "Bahnhofstrasse";
  emp.Address.City = "Zürich";
}

Попробуйте написать такой метод с помощью результирующих наборов, и вы знаете, что такое невежество.

Если вы не уверены, посмотрите, насколько простым будет unit test, потому что нет никаких зависимостей от материала, связанного с сохранением:

Employee emp = new Employee();
MovingService.MoveToZuerichBahnhofstreasse(emp);
Assert.AreEqual("Bahnhofstrasse", emp.Address.Street);
Assert.AreEqual("Zürich", emp.Address.City);

DDD - это нечто другое. Там вы сначала создаете свою модель домена (модель класса) и создаете дизайн базы данных в соответствии с ней. С NH это очень просто, потому что - благодаря незнанию персистентности - вы можете написать и unit test модель и логику, прежде чем иметь (окончательную) модель базы данных.

Тестирование. Мы тестируем сопоставления, создавая экземпляр объекта, сохраняя его в базе данных, возвращая его и сравнивая. Это делается автоматически с большим количеством отражения. Но вам не нужно заходить так далеко. большинство типичных ошибок появляются при попытке сохранить объект.

Вы можете сделать то же самое с запросами. Комплексные запросы заслуживают тестирования. Это наиболее интересно, если запрос компилируется вообще. Вам даже не нужны данные для этого.

Для тестов интеграции базы данных мы используем Sqlite. Это довольно быстро. NH создает базу данных в памяти на лету, используя SchemaExport (перед каждым тестом).

Ответ 2

Я всегда думал с точки зрения домена, и, хотя я использовал хранимые процедуры, в прошлом ADO.NET, только когда я, наконец, перешел в NHibernate, я был доволен своим механизмом сохранения.

Domain Driven Design (DDD) делает акцент прямо на модели домена. Это означает, что основное внимание уделяется созданию концептуальной модели, которая формирует общий язык как для пользователей, так и для программистов. Пользователи почти НИКОГДА не заинтересованы в том, как вы сохраняете свою информацию. NHibernate помогает вам достичь этого мышления, делая упор на беспокойство, которое вторгается в захват бизнес-правил и понимание того, что пользователь действительно хочет от системы.

Fluent NHibernate уменьшает влияние, которое изменения в вашей модели домена оказывают на базовые файлы сопоставления. Он также имеет автоматическое сопоставление. Хотя вы никогда не можете полностью игнорировать постоянство своей системы, NHibernate с Fluent NHibernate позволяет сосредоточиться на модели домена. Если вы не фокусируетесь на использовании богатой модели домена, для NHibernate мало преимуществ.

Что касается тестирования ваших сопоставлений, вы будете писать тесты (или вы ДОЛЖНЫ быть), независимо от того, какой метод вы используете для реализации настойчивости. Это не лишняя работа, которая появляется только потому, что вы используете NHibernate. Подумайте о том, как тестировать ваши сопоставления как тестирование, чтобы ваша настойчивость работала правильно.

Снова для этого Fluent NHibernate бесценен. Он получил "Проверка спецификаций настойчивость" , который очень прост в использовании для большинства случаев.

Ответ 3

PI не использует NHibernate. PI означает игнорирование того, как данные будут храниться при разработке модели домена. И да, это толкает зависимость, добавляя еще один уровень абстракции. DDD не является революционным - это больше похоже на идею, подход, как кодировать, используя уже знакомые шаблоны (большинство из них). То есть - factory шаблон шаблона или модуля не является новым, но довольно важной частью DDD.

Я начал использовать NHibernate совсем недавно, поэтому - не могу предоставить подробностей об этом. Но у меня есть один совет, который может быть полезен для вас - попробуйте Fluent NHibernate, если вы еще этого не сделали.