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

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

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

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

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

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