|
|
|
| Где вы делаете обработку данных из базы, в модели, в контроллере или представлении?
Например если надо отфильтровать теги из данных, или что-то другое, отформатировать ISBN, в базе есть строка "9780596516178", которая у клиента должна выглядеть так "978-0596516178".
Спасибо. | |
|
|
|
|
|
|
|
для: 502
(23.07.2011 в 23:16)
| | Модель - это традиционно база данных, чем большая часть модели будет находиться в области базы данных - тем лучше. Однако, разнести "красиво" и ООП-выдержано модель и контроллер не всегда представляется возможным. СУБД - это реляционная философия, она очень в разрез идет с ООП и вообще с иерархиями, куча шаблонов посвящена скрещиванию ООП и СУБД. Кроме того шаблон модель, контроллер и представление может использоваться во многих частях системы, на разных этапах жизнедеятельности Web-приложения, т.е. MVC у вас может быть много и в разных частях системы.
>Например если надо отфильтровать теги из данных
Что за тэги и как они там очутились (тэги бывают разные и задачи работы с ними тоже разные - если это ошибка проектирования, лучше если модель постарается избавить всю цепочку от этой головной боли, если тэги за делом, то пусть контроллер - подготовит данные для представления, так как в представление это безобразие (если только это не bbCode) пускать не стоит - уже не безопасно)?
>или что-то другое, отформатировать ISBN, в базе есть строка "9780596516178", которая у клиента
>должна выглядеть так "978-0596516178".
Это задача для представления, чем позднее вы его будет осуществлять, тем лучше... идеально, если форматированием этой строки займется JavaScript на стороне клиента и разгрузит и без того загруженный сервер. Хотя, конечно, ничто не мешает осуществить форматирование на уровне модели (т.е. база данных в запросе вставит это тире) или на уровне контроллера, PHP-скрипт при извлечении данных и передачи их блоку представления вставит это тире. Но с точки зрения ООП - это задача представления. | |
|
|
|