Отрыв от MVC

Question

В последнее время я пытался улучшить / отойти от стандартной установки MVC для веб-разработки, и я подумал, что пора бросить свои идеи в StackOverflow.

Общий поток такой же, как при начальной загрузке создает начальные объекты. Разница в том, что они хранятся в ServiceManager.

Затем, вместо отправки контроллера, он загружает представление.

Затем представление вызывает Команды и Запросы. Команды представляют функциональность, которая, как правило, связана с формой (обычно обновляет строки базы данных), а запросы - это то, что обычно будет ModelPeers. Когда они создаются (через ServiceManager), им передается ServiceManager, что избавляет от необходимости большого количества потенциально сложных инъекций зависимостей.

Сами модели просто создают / обновляют / удаляют в одной строке.

Таким образом, вид будет выглядеть так:

ListUsers.php

<?php $users = $this->ServiceManager->get('Query\User')->getNewestUsers(10); ?>

<?php foreach($users as $user): ?>
....
<?php endforeach; ?>

UpdateUser.php

<?php $this->ServiceManager->get('Command\User')->update(); ?>

<form>...</form>

Я знаю, что есть какое-то нарушение уровня, но это кажется намного чище, чем иметь набор контроллеров, которые действуют больше как ViewVariableSetters, чем что-либо еще.

Это также делает все гораздо более тестируемым, поскольку все функциональные возможности инкапсулированы в Команды и Запросы и удалены от больших контроллеров. Технически, у меня мог бы быть контроллер или ViewVariableSetter, но кажется, что он добавил бы намного больше кода с очень небольшим преимуществом.

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

Answer 1

Если вам не нравится MVC, вы можете посмотреть на его родных MVP ( Model-View-Presenter ), PM ( Presentation Model ) и MVVM ( Model -Просмотр-ViewModel ).

На самом деле, то, что вы описываете, может быть PM, я не уверен.

Answer 2

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

Answer 3

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

Мое мнение: возможно, проблема не столько в «MVC», сколько в нынешней догме о «V» (взгляд). Похоже, что в настоящее время догма заключается в том, что представление должно быть шаблоном (HTML), в котором код должен быть вплетен в "объект d 'art". Можно утверждать, что для многих приложений это просто работа.

Возможно, нам нужна более совершенная / альтернативная технология просмотра: при настройке задачи редактирования CRUD, в отличие от маркетингового киоска (который должен быть произведением искусства), мы создаем API для генерации формы и другие элементы пользовательского интерфейса, использующие модель "DOM", такую ​​как javascript в браузере (или как java AWT)? Просто мысль.

---

В ответ на комментарий:

"... я хочу избежать использования класса, который просто передает данные в представление ..."

Прежде всего, это должно быть выполнимо, чтобы сделать это минимальным количеством кода, когда это минимальное количество работы. Например, мне нравится, как «Rails» автоматически направляет запросы в пределах определенной «области» приложения в класс, сопоставляя запросы с отдельными функциями / обработчиками. Я эмулировал это поведение в коде Java, чтобы сделать ответы более краткими.

Во-вторых, эта «передача информации в представление» является просто конкретным случаем «вычисления и хранения, передачи данных по конвейеру простых шагов». Это облегчает понимание и поддержку кода. Я не хардкорный поклонник «функционального программирования», но есть кое-что, что можно сказать, чтобы иметь возможность (легко) понимать поток данных в куске кода. Как дополнительное преимущество, это часто (кажется, неинтуитивно) заставляет код на самом деле работать немного быстрее. Раньше я слышал про "местность", поэтому не буду повторять это здесь.

Answer 4

MVC - это немного странный дизайн для Интернета. В большинстве случаев вам не нужно разделение между представлением и контроллером. С другой стороны, поскольку URL действует как состояние приложения, вам необходим некоторый уровень взаимодействия между ними. Это приводит к одному из двух сценариев; Либо вы получаете только частичное разделение, либо вы получаете много сложности. Ни один из них не очень полезен.

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

Хотя есть кое-что, что можно сказать об использовании отраслевого стандарта - хотя и неправильного - просто потому, что это стандарт. Если вы создадите свою собственную архитектуру, другим разработчикам будет сложнее понять ее. Вы не должны недооценивать, сколько работы уходит на то, чтобы получить что-то подобное просто правильно.

Answer 5

Как вы будете настраивать вид для соответствия различным форматам? Например, ответ html, ответ json и т. Д.