1) Я использую простой доморощенный набор классов для некоторых своих материалов MVC, и он связывает имена контроллеров с именами действий и представлений (это стиль Front Controller, похожий на Zend). Для общего веб-сайта предположим, что он имеет домашнюю страницу, политику конфиденциальности, контактную страницу и страницу с информацией. Я действительно не хочу делать отдельные контроллеры для всех этих вещей, поэтому я буду вставлять их в свой IndexController с именами функций, такими как actionIndex(), actionPrivacy(), actionContact() и actionAbout().
Чтобы согласиться с этим, внутри моего каталога Views у меня есть каталог шаблонов, связанных с каждым действием. По умолчанию любое действие автоматически ищет связанный шаблон, хотя вы можете указать его, если хотите. Таким образом, actionPrivacy() будет искать файл шаблона в index/privacy.php, actionContact() будет искать index/contact.php и т. д.
Конечно, это относится и к URL-адресам. Таким образом, URL-адрес, попадающий на http://www.example.com/index/about, будет запускать actionAbout(), который загрузит шаблон страницы «О программе». Поскольку страница about является полностью статическим содержимым, мой actionAbout() абсолютно ничего не делает, кроме предоставления публичного действия, которое Front Controller может увидеть и запустить.
Итак, чтобы ответить на суть вашего вопроса, я помещаю несколько «страниц» в один контроллер, и он отлично работает для моих целей. Одна модель для каждого контроллера — это теория, которой я бы не стал следовать при работе с Web MVC, поскольку она гораздо лучше подходит для приложения с состоянием.
2) Для этого у меня было бы несколько контроллеров. Следуя тем же методам, которые я использовал выше, я бы получил /admin/dashboard и /account/dashboard, как вы предлагаете, хотя нет никаких причин, по которым они не могли бы использовать одни и те же (или части одних и тех же) шаблонов.
Я полагаю, что если бы у меня было огромное количество разных пользователей, я бы сделал вещи более универсальными и использовал бы только один контроллер, а также имел бы правило mod_rewrite для обработки загрузки. Вероятно, это будет зависеть от того, насколько функционально сложна панель инструментов и как настроена учетная запись.
3) Я считаю, что функциональные возможности CRUD трудно внедрить непосредственно в любой уровень MVC, и при этом они должны быть чистыми, гибкими и эффективными. Мне нравится абстрагировать функциональные возможности CRUD на сервисный уровень, к которому может обращаться любой объект, и иметь базовый класс объектов, из которого я могу расширять любые объекты, нуждающиеся в CRUD.
Я бы предложил использовать некоторые из фреймворков PHP ORM для CRUD. Они могут избавиться от многих хлопот, связанных с получением хорошей реализации.
С точки зрения контроллера входа в систему по сравнению с пользовательским контроллером, я полагаю, это зависит от вашего домена приложения. С моим стилем программирования я склонен думать о «входе в систему» как о простой операции в домене модели пользователя и, следовательно, иметь для нее одну операцию внутри пользовательского контроллера. Чтобы быть более точным, я хотел бы, чтобы UserController создавал модель пользователя и вызывал процедуру входа в модель. Я не могу сказать вам, что это правильный путь, потому что я не мог точно сказать, каким должен быть правильный путь. Это вопрос контекста.
4) Вы правы насчет свободы действий. Вы можете легко создать контроллер, который будет обрабатывать все, что нужно вашему приложению/сайту. Тем не менее, я думаю, вы согласитесь, что это станет кошмаром для обслуживания. Меня до сих пор мучают мысли о моей последней работе в компании по исследованию рынка, где внутреннее PHP-приложение было сделано зарубежной командой, которая, как я могу предположить, практически не обучалась. Мы говорим о скриптах на 10 000 строк, которые обрабатывают весь сайт. Удержать было невозможно.
Итак, я предлагаю вам разбить ваше приложение/сайт на области бизнес-доменов и создать контроллеры на их основе. Выясните основные концепции вашего приложения и двигайтесь дальше.
Пример
Скажем, у меня был веб-сайт о ламантинах, потому что ламантины, очевидно, крутые. Я хотел бы несколько обычных страниц сайта (о, контакты и т. д.), управление учетными записями пользователей, форум, галерею изображений и, возможно, область исследовательского документа (с последними научными данными о ламантинах). Довольно просто, и многое из этого было бы статичным, но вы можете начать видеть разбивку.
IndexController — обрабатывает страницу, политику конфиденциальности, общий статический контент.
UserController — обрабатывает создание учетной записи, вход/выход, настройки
PictureController - отображать картинки, обрабатывать загрузки
ForumController - наверное, не очень, я бы попробовал интегрировать внешний форум, а значит, мне не нужно было бы много функционала здесь.
LibraryController - показать списки последних новостей и исследований
HugAManateeController - виртуальный ламантин обнимается в реальном времени через HTTP
Это, вероятно, дает вам хотя бы базовое разделение. Если вы обнаружите, что контроллер становится очень большим, вероятно, пришло время разбить бизнес-домен на отдельные контроллеры.
Для каждого проекта она будет разной, поэтому небольшое планирование имеет большое значение для того, какая архитектурная структура у вас будет.
Web MVC может быть очень субъективным, поскольку он сильно отличается от модели MVC, в которой ваше приложение имеет состояние. При работе с веб-приложениями я стараюсь не давать контроллерам основную функциональность. Мне нравится, когда они создают экземпляры нескольких объектов или моделей, запускают пару методов в зависимости от выполняемого действия и собирают некоторые данные представления, чтобы передать их представлению после выполнения. Чем проще, тем лучше, и я поместил основную бизнес-логику в модели, которые должны отражать состояние приложения.
Надеюсь, это поможет.
person
zombat
schedule
29.04.2009
