Табличный модуль против модели предметной области

Лучшая ссылка - это «Шаблоны архитектуры корпоративных приложений» Мартина Фаулера:

Вот выдержка из раздела Табличный модуль:

A Table Module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model is that, if you have many orders, a Domain Model will have one order object per order while a Table Module will have one object to handle all orders.

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

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

Вместо этого модуль таблицы упрощает кодирование логики, которая применяется к нескольким строкам в базовой таблице базы данных. Если вы создаете профиль для данного пользователя, вы должны указать все эти свойства, и класс Table Module будет иметь код для преобразования этого в серию операторов INSERT, по одной строке на свойство.

$table->setUserProfile( $userid, array('firstname'=>'Kevin', 'lastname'=>'Loney') );

Точно так же при запросе профиля данного пользователя будет использоваться модуль таблицы для сопоставления нескольких строк набора результатов запроса с членами объекта.

$hashArray = $table->getUserProfile( $userid );