Каким будет мой контроллер в этих сценариях в веб-приложении mvc?

Question

1) Где домашняя страница вашего сайта вписывается в «контроллеры»? Я видел, как некоторые люди используют контроллер «page» для обработки статических страниц, таких как, about, home, contact и т. Д., Но мне это не кажется хорошей идеей. Будет ли лучше создать отдельный контроллер для вашей домашней страницы? В конце концов, ему может потребоваться доступ к нескольким моделям, и он не очень хорошо сочетается с целым, один контроллер на теорию модели, которую используют некоторые люди.

2) Если вам нужна панель мониторинга для нескольких типов пользователей, будет ли это один контроллер панели мониторинга, у которого код переключения будет зависеть от того, от какого пользователя, или вы скажете действие панели мониторинга в каждом контроллере для каждого пользователя? Например, admin / dashboard, account / dashboard и т. Д.

3) Мне кажется, что при попытке объяснить контроллеры использование всего простого примера CRUD работает как обаяние, но когда вы преодолеете эти простые функции, он сломается и может привести к тому, что ваши контроллеры станут громоздкими. Почему некоторые люди предпочитают создавать контроллер входа в систему, когда другие выполняют функцию входа в пользовательский контроллер? Одна из причин, по которой я думаю, заключается в том, что многие из нас имеют опыт работы с страницами, и о контроллерах трудно думать как о «объектах» или «существительных», потому что страницы не всегда работают таким образом. Например, почему вы захотите создать контроллер «страниц», который будет обрабатывать страницы, которые на самом деле не имеют никакого отношения друг к другу, просто чтобы иметь «контейнер» для размещения действий. Просто мне не кажется правильным.

4) Должны ли контроллеры иметь большее отношение к варианту использования, чем к «объекту», над которым можно выполнять действия? Для всех интенсивных целей вы можете создать пользовательский контроллер, который выполняет все действия во всем приложении. Или вы можете создать контроллер для каждой «проблемной области», как некоторые любят говорить. Или вы можете создать один контроллер для просмотра, если хотите. Существует так много возможностей, что затрудняет поиск согласованного метода для использования.

Контролеры не должны быть такими запутанными, вероятно, но по какой-то причине они выводят меня из себя. Будем благодарны за любые полезные комментарии.

Answer 1

1) Для некоторых вещей из MVC я использую простой набор классов по-домашнему, и он связывает имена контроллеров с именами действий и представлений (это стиль Front Controller, похожий на Zend). Для общего веб-сайта, давайте предположим, что у него есть домашняя страница, политика конфиденциальности, страница контактов и страница о программе. Я действительно не хочу создавать отдельные контроллеры для всех этих вещей, поэтому я вставлю их в мой IndexController с именами функций, такими как actionIndex(), actionPrivacy(), actionContact() и actionAbout().

Для этого внутри моего каталога Views у меня есть каталог шаблонов, связанных с каждым действием. По умолчанию любое действие автоматически ищет связанный шаблон, хотя вы можете указать его, если хотите. Поэтому actionPrivacy() будет искать файл шаблона в index/privacy.php, actionContact() будет искать index/contact.php и т. Д.

Конечно, это относится и к URL. Таким образом, при переходе по ссылке http://www.example.com/index/about будет запущен actionAbout(), что приведет к загрузке шаблона страницы About. Поскольку страница about является полностью статическим содержимым, мой actionAbout() абсолютно ничего не делает, кроме как предоставляет публичное действие, которое Front Controller может увидеть и запустить.

Итак, чтобы ответить на суть вашего вопроса, я помещаю несколько «страниц» в один контроллер, и он отлично работает для моих целей. Одна модель для каждого контроллера - это теория, которую я не думаю, что буду пытаться следовать при работе с Web MVC, поскольку кажется, что она лучше подходит для приложения с состоянием.

2) Для этого у меня будет несколько контроллеров. Следуя тем же методам, которые я использовал выше, у меня были бы /admin/dashboard и /account/dashboard, как вы предлагаете, хотя нет причин, по которым они не могли бы использовать одни и те же (или части тех же) шаблонов.

Полагаю, если бы у меня было несколько миллиардов пользователей, я бы сделал все более универсальным и использовал бы только один контроллер и имел бы правило mod_rewrite для обработки загрузки. Вероятно, это будет зависеть от того, насколько функционально сложна панель мониторинга и как настроена учетная запись.

3) Мне кажется, что функциональность CRUD сложно внедрить непосредственно в любой слой MVC, но при этом она должна быть чистой, гибкой и эффективной. Мне нравится абстрагировать функциональность CRUD в сервисный уровень, к которому может обращаться любой объект, и иметь базовый класс объектов, из которого я могу расширять любые объекты, требующие CRUD.

Я бы предложил использовать некоторые платформы PHP ORM для CRUD. Они могут избавиться от многих хлопот, связанных с получением хорошей реализации.

С точки зрения контроллера входа и пользовательского контроллера, я полагаю, это зависит от домена вашего приложения. С моим стилем программирования я склонен думать о «входе в систему» ​​как о простой операции в области пользовательской модели и, таким образом, иметь одну операцию для нее внутри пользовательского контроллера. Чтобы быть более точным, я хотел бы UserController создать экземпляр модели пользователя и вызвать процедуру входа в систему для модели. Я не могу сказать вам, что это правильный путь, потому что я не мог точно сказать, каким должен быть правильный путь. Это вопрос контекста.

4) Вы правы насчет свободы действий. Вы можете легко создать контроллер, который обрабатывает все, что хочет сделать ваше приложение / сайт. Тем не менее, я думаю, вы согласитесь, что это станет кошмаром обслуживания. Я до сих пор думаю о jibbly-jibblies о моей последней работе в компании, занимающейся исследованиями рынка, где внутреннее PHP-приложение было создано зарубежной командой, и я могу только предположить, что это было обучение практически без тренировок. Мы говорим о 10000 строчных сценариях, которые обрабатывали весь сайт. Это было невозможно поддерживать.

Итак, я бы предложил вам разбить ваше приложение / сайт на области бизнес-доменов и создать на его основе контроллеры. Разберитесь с основными понятиями вашего приложения и перейдите оттуда.

Пример

Допустим, у меня был веб-сайт о ламантинах, потому что, очевидно, ламантины качаются. Я хотел бы иметь несколько обычных страниц сайта (о, контакты и т. Д.), Управление учетными записями пользователей, форум, галерею изображений и, возможно, область материалов исследовательских документов (с последними научными знаниями о ламантинах). Довольно просто, и многое из этого будет статичным, но вы можете начать видеть разбивку.

IndexController - обрабатывает страницу, политику конфиденциальности, общий статический контент.

UserController - управляет созданием аккаунта, входом / выходом, настройками

PictureController - отображать картинки, обрабатывать загрузки

ForumController - вероятно, не так много, я бы попытался интегрировать внешний форум, что означало бы, что мне не нужно много функциональности здесь.

LibraryController - показывать списки последних новостей и исследований

HugAManateeController - виртуальное ламантиновое объятие в реальном времени по HTTP

Это, вероятно, дает вам хотя бы базовое разделение. Если вы обнаружите, что контроллер становится очень большим, возможно, пришло время разделить бизнес-область на отдельные контроллеры.

Это будет отличаться для каждого проекта, поэтому небольшое планирование имеет большое значение для определения типа архитектурного сооружения.

Web MVC может стать очень субъективным, поскольку он сильно отличается от модели MVC, в которой ваше приложение имеет состояние. Я стараюсь не использовать основные функции контроллеров при работе с веб-приложениями. Мне нравится, что они создают экземпляры нескольких объектов или моделей, запускают несколько методов, основанных на предпринятом действии, и собирают некоторые данные View, чтобы передать их в View, когда он будет выполнен. Чем проще, тем лучше, и я поместил основную бизнес-логику в модели, которые должны представлять состояние приложения.

Надеюсь, это поможет.