Насколько абстрактными должны быть модели MVC?
Я занимаюсь расширением и улучшением веб-сайта, который имеет несколько структурных проблем. Похоже, что разработчики до меня слышали о MVC, но не понимали идей абстракции или модульности. Итак, «фреймворк» MVC: а) сделан на заказ, б) сломан, в) исправлен и г) их несколько одновременно используются. Я собираюсь это исправить.
Это не первый раз, когда я перестраиваю фреймворк сайта, BTW, но это первый раз, когда мне приходилось исправлять фреймворк MVC. Однако здесь, на SO, я сталкиваюсь с некоторыми недостающими пробелами в знаниях MVC.
Во-первых, насколько тесно программисты связывают свою базу данных SQL со своими моделями. Для меня это не имеет смысла: обычно ли у программистов есть модель, заботящаяся об абстракции данных? (Для меня это немного лучше, чем помещать SQL в необработанный PHP-код.) Или существует обычно используемый уровень доступа к данным, который «делает ли SQL»? По опыту я знаю, что последнее означает, что вызывающему коду не нужно беспокоиться о том, где находятся данные, или как их получить или как их записать: API обрабатывает это.
А как насчет моделей? Предназначены ли они для повторного использования на разных страницах? Должны ли они заботиться о том, где хранятся данные? Разве им не следует больше заботиться об обработке логики между выборкой данных и показом данных (например, превращение идентификатора группы контакта в отображаемое имя)? И сохранение данных, и запись данных (например, выяснение того, как превратить значения $ _POST в сохраняемые данные)?
Может быть, модель MVC действительно будет DMVC - Data-Model-View-Controller.
Наконец, хотя это и с точки зрения PHP, насколько хорошо эти концепции переносятся на сайт JSP?
Ответы 2
Здесь вы найдете более одного потока о том, следует ли начинать работу со схемы базы данных или с пользовательского интерфейса. Есть одно место, куда можно смотреть.
Я могу придумать гораздо больше, чем один инструмент, который берет схему и создает для вас ваш CRUD UI («строительные леса»), чем наоборот. Есть еще одно место, куда можно смотреть. (Ребенок-плакат: Ruby on Rails и его когнитивное потомство).
При обсуждении инструментов ORM слишком часто (но не всегда) предпочтительным акронимом будет «ROM».
У нас есть много инструментов, которые ободряют нас в нашей злой склонности к «Готовься, стреляй, целься». Для руководства это самая короткая линия между «Proof of Concept» и «RC1».
А как насчет моделей? Предназначены ли они для повторного использования на разных страницах?
да.
Должны ли они заботиться о том, где хранятся данные?
Нет. Им не нужно этого знать. Вся эта своего рода информация необходима для уровня сохраняемости или уровня данных.
Разве им не следует больше заботиться об обработке логики между выборкой данных и показом данных (например, превращение идентификатора группы контакта в отображаемое имя)?
Нет. Их просто беспокоит бизнес-логика. Какое-то обычное приложение, которое я обнаружил, люди делают модель тупой, просто имея атрибуты / свойства и ничего больше. Типичным примером в Java является POJO с геттерами / сеттерами. Мы называем их TO (объекты передачи) и используем их повсюду как хранилища данных. Я не совсем согласен с этим, ИМО, должны быть какие-то методы, связанные с бизнесом, которые подходят и соответствуют требованиям. Не делай это так глупо. Новые Entity Beans (EJB3) - хороший тому пример.
Кстати, показ данных - это работа уровня представления. В java JSP является частью технологии просмотра.
И сохранение данных, и запись данных (например, выяснение того, как превратить значения $ _POST в сохраняемые данные)?
Нет. Обычно это делается в наших контроллерах, большую часть времени используя некоторые служебные классы.
Передача объектов ... это имя, которое я искал! Я думаю, что ключевым моментом для MVC является заполнение (что угодно, кроме представления) этими объектами передачи и передача их в шаблон. Шаблон ожидает структуру TO и использует данные для создания красивого отображения. Просто как тот.
Я думаю, что «RFA» используется с MVC. Слишком высокий процент фреймворков MVC и сторонников того, что нет абстрагируют хранилище данных. :-( Фреймворки "автомодели" кажутся худшими нарушителями.