Почему бы не разделить слой доступа к данным на две части? - PullRequest
0 голосов
/ 19 февраля 2011

Куда бы я ни посмотрел, я заметил, что подходы Domain Driven Design (DDD) и гидратации сущностей пытаются заполнить сущности непосредственно из уровня данных. Я не согласен с такими подходами. Это не потому, что эти подходы не работают, потому что они работают. Вместо этого я бы сказал, что такие подходы обеспечивают низкий уровень прозрачности для целей тестирования. Я предлагаю, чтобы на уровне доступа к данным данные извлекались для заполнения словарей вместо непосредственного заполнения самими сущностями. Для этого есть несколько причин:

Во-первых, есть большая гибкость. Словарь для каждого набора результатов может быть заполнен. Позже мы решим, какие объекты можно заполнить из этих наборов результатов.

Во-вторых, требуется меньше знаний об уровне данных, чтобы определить, где происходит сбой при получении данных. Мы по-прежнему можем писать тесты для проверки извлечения данных без необходимости что-либо понимать о связанных с ними фабриках сущностей сложных доменов.

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

1 Ответ

2 голосов
/ 24 февраля 2011

Кажется, что проблема в тестировании («в целях тестирования»), поэтому я предлагаю вам использовать репозитории , как указывал @tschmuck.

Как указывает Айенде, они могут дать вам ненужный код лазаньи (т.е. слишком много слоев), но они дадут вам гибкость.Вы можете самостоятельно реализовать фальшивые / тестовые шпионы, макетировать и заглушки, а также использовать БД в памяти, такую ​​как SQLite, и зависимый класс будет таким же счастливым.

...