Здравствуйте, mife, Вы писали:
N>>Модуль таблицы в простейшем случае — просто массив данных, к которому можно обращаться через какие-либо итераторы, где каждая итерация возвращает строку (а строка уже может собой представлять либо объект наподобие активной записи, либо просто набор значений в виде еще одного массива).
M>То что Вы написали — это RecordSet (в терминологии Фаулера), а не модуль таблицы
Почитайте внимательно Фаулера (если у вас русский вариант, см. стр. 149, Принцип действия, второй абзац) — он там и говорит, что в частном случае модуль таблицы содержит RecordSet, и при отсутствии сложной бизнес-логики их можно приравнять (тем более, что я написал "в простейшем случае"). И хотя в последующих примерах он отделил это с помощью Data Table Gateway, никто не мешает вам использовать их вместе — два в одном.
M>>>Можно завести для каждой таблицы базы модуль, но кто в таком случае будет проводить вычисления C?
N>>За это отвечает модуль бизнес-логики — он может быть промежуточным между модулем таблицы и представлением (паттерн Преобразователь данных).
M>Нет уж, извините, опять же, по Фаулеру, модуль таблицы как раз и реализует бизнес-логику.
M>По моему Вы путаете то что Фаулер называет шлюзом таблицы и модулем таблицы. Это (в идеале) разные вещи. Т.к. пример простой, можно считать что у нас — идеальный случай.
Это уже зависит от того, какую архитектуру вы построете. Если C работает с независимыми сущностями, не завязанные ни на какие данные, то логично их вынести в отдельный слой. Модуль таблицы отвечает в основном за такие вещи которые завязаны на данные, например, валидация. Единственное, я неправильно выразился — это просто паттерн Преобразователь.
M>Предположим поэтому, что то что я назвал форматированием — в действительности сложная обработка, относящаяся к бизнес-логике.
Нет уж, называйте вещи своими именами. Форматирование относится именно к GUI, и к бизнес-логики это отношения не имеет. Это может быть просто сложная логика, требующая интенсивной работы с данными, и тогда можно создать дополнительный уровень косвенности, но все-равно это будет относится к View.
