Я читаю главу архитектурных паттернов POEAA, и Фаулер говорит, что «по мере усложнения логики домена, и вы начинаете двигаться к богатой модели домена (116), простой подход к активной записи (160) начинает разрушаться . Индивидуальное совпадение классов домена с таблицами начинает терпеть неудачу, поскольку вы определяете логику домена на более мелкие классы. Реляционные базы данных не обрабатывают наследование, поэтому становится трудно использовать стратегии [Gang of Four] и другие опрятные шаблоны OO Поскольку логика домена становится злющей, вы хотите проверить ее без необходимости постоянно разговаривать с базой данных ».
Я этого не понимал. Посредством «один к одному совпадению классов домена с таблицами» означает ли это только для классов, в которых нет ассоциаций или иерархии иерархии отдельных таблиц?
И почему факторизация доменной логики на более мелкие классы приводит к сбою шаблона?
То, что он пытается сказать, заключается в том, что более сложные модели домена обычно больше, чем просто «данные из таблицы». Эти более сложные модели, о которых говорит Фаулер, – это модели, которые получают данные из разных таблиц, представлений или, возможно, даже из других источников.
Образец Active Record не подходит для этой цели, и шаблон DataMapper в сочетании с только классами моделей (содержащий только бизнес-логику и не взаимодействующий с уровнем доступа к данным), вероятно, более подходит в таких ситуациях.
Здесь отсутствует шаблон Active Record, поскольку он более или менее напрямую сопоставляется с таблицей в базе данных.
Я не знаю точное определение шаблона, поэтому, пожалуйста, исправьте меня, если я ошибаюсь.
Нет, я думаю, он говорит о логике домена. При активной записи объект несет как данные, так и поведение. Так что это матч один к одному. Если вы начнете разделять данные / поведение, как в шаблоне Data Mapper, он становится «один ко многим». У меня сложилось впечатление, что вам иногда действительно приходится читать эту книгу, как академическую чепуху, чтобы понять, что он имеет в виду. 🙂