Спасибо за Ваше внимание к моему вопросу, Nuald.

N>Почитайте внимательно Фаулера (если у вас русский вариант, см. стр. 149, Принцип действия, второй абзац) — он там и говорит, что в частном случае модуль таблицы содержит RecordSet, и при отсутствии сложной бизнес-логики их можно приравнять (тем более, что я написал "в простейшем случае"). И хотя в последующих примерах он отделил это с помощью Data Table Gateway, никто не мешает вам использовать их вместе — два в одном.

Эх, позвольте я проясню цели своего вопроса. Я хочу разобраться в понятниях, используемых Фаулером. Для этого я прошу на примере продемонстрировать как они работают. Из ответа должна быть видна разница между понятиями. А Вы мне предлагаете все смешать. Мне от этого понятней не станет.
Грубо говоря, я спрашиваю, чем водка отличается от пива, а мне предлагают смешать их. Это несомненно более действенное решение, если нужно забыться, но я не ищу решения — я хочу понять разницу.

M>>>>Можно завести для каждой таблицы базы модуль, но кто в таком случае будет проводить вычисления C?
N>>>За это отвечает модуль бизнес-логики — он может быть промежуточным между модулем таблицы и представлением (паттерн Преобразователь данных).
M>>Нет уж, извините, опять же, по Фаулеру, модуль таблицы как раз и реализует бизнес-логику.
M>>По моему Вы путаете то что Фаулер называет шлюзом таблицы и модулем таблицы. Это (в идеале) разные вещи. Т.к. пример простой, можно считать что у нас — идеальный случай.

N>Это уже зависит от того, какую архитектуру вы построете. Если C работает с независимыми сущностями, не завязанные ни на какие данные, то логично их вынести в отдельный слой. Модуль таблицы отвечает в основном за такие вещи которые завязаны на данные, например, валидация. Единственное, я неправильно выразился — это просто паттерн Преобразователь.

Опять же, можно вводить дополнительные слои и т.п., это решает задачу. Но не имеет отношения к целям моего вопроса. В одном из примеров Фаулера модуль таблицы занимается определением зачтенного дохода. Это самая настоящая бизнес-логика, а не простая валидация.

Мой вопрос сводится на самом деле вот к чему: неужели паттерн Модуль Таблицы так плох, что даже в простых задачах требует введения дополнительных слоев?

M>>Предположим поэтому, что то что я назвал форматированием — в действительности сложная обработка, относящаяся к бизнес-логике.

Поясню — я немного изменил условия задачи. Забыли слово "форматирование" — над полем F выполняется операция, по сути относящаяся к бизнес-логике (ну какой-нибудь расчет сложного процента, например)