альтернатива MVC, которая слабо связана? - PullRequest
7 голосов
/ 30 апреля 2009

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

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

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

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

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

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

Итак, мой вопрос: существует ли шаблон проектирования для создания и поддержки веб-сайтов, который гораздо более слабо связан? Я не ищу незначительных изменений в MVC, мне нужно что-то совсем другое, возможно, какой-то подход к плагину.

EDIT:

Спасибо за ответы, пока! Иными словами, я хочу, чтобы код был лучше в моем офисе. Должен ли я A) добиваться MVC или B) найти / построить альтернативу, не столь запутанную для полупрограммистов. Мы уже используем классы для таких вещей, как подключение к БД и помощь в форме. Смысл этого вопроса состоял в том, чтобы исследовать Б.

Ответы [ 8 ]

3 голосов
/ 30 апреля 2009

По мере использования шаблонов фреймворков я считаю, что шаблон MVC является одним из наиболее "слабо связанных" способов создания приложения.

Подумайте об отношениях, таких как интерфейсы или контракты между частями приложения. Модель обещает сделать эти данные доступными для просмотра и контроллера. Никого не волнует, точно как Модель делает это. Он может читать и писать из типичной СУБД, такой как MySQL, из плоских файлов, из внешних источников данных, таких как ActiveResource, при условии, что он завершит сделку.

Контроллер обещает сделать определенные данные доступными для Представления и полагается на Модель для выполнения своих обещаний. Представлению все равно как Контроллер делает это.

Представление предполагает, что Модели и Контроллеры будут выполнять свои обещания, и затем могут быть разработаны в вакууме. Модели и контроллеру все равно, генерирует ли представление XML, XHTML, JSON, YAML, открытый текст и т. Д. Они задерживают выполнение своих контрактов.

И, конечно, View и Controller должны согласиться с тем, что определенные вещи существуют. Представление без некоторого соответствующего действия контроллера может работать нормально, но никогда не может быть использовано. Даже если контроллер не ничего не делает , как это может быть в случае статических страниц:

<?php
class StaticController extends ApplicationController
{

    /**
     * Displays our "about" page.
     */
    public function about ()
    {
        $this->title = 'About Our Organization';
    }
}

Тогда связанный View может просто содержать статический текст. (Да, я реализовал подобные вещи раньше. Приятно передать статический вид кому-то еще и сказать «Просто напишите об этом».)

Если вы посмотрите на отношения между M, V и C как на контракты или интерфейсы, MVC внезапно выглядит очень «слабо связанным». Будьте осторожны с приманкой автономных файлов PHP. Как только вы начнете включать и требовать полдюжины файлов .inc или смешать логику приложения с вашим дисплеем (обычно HTML), вы, возможно, связали отдельные страницы более свободно, но в процессе запутались важные аспекты.

<?php
/**
 * Display a user's profile
 */
require_once 'db.php';

$id = $db->real_escape_string($_GET['id']);
$user_res = $db->query("SELECT name,age FROM users WHERE id = $id;");
$user = $user_res->fetch_assoc();

include 'header.php';
?>
<h1><?php echo $user['name']; ?>'s Profile</h1>

<p><?php echo $user['name']; ?> is <?php echo $user['age']; ?> years old!</p>
<?php
include 'footer.php';
?>

Да, "profile.php" и "index.php" совершенно не связаны, но какой ценой?

Редактировать: В ответ на ваше редактирование: Нажмите для MVC. Вы говорите, что у вас есть «полупрограммисты», и я не уверен, какая половина (есть ли у вас люди с интерфейсом, которые хорошо разбираются в HTML и CSS, но не работают на стороне сервера? Писатели с некоторым опытом программирования?), Но с MVC Framework, вы можете передать им только представления и сказать «работать над этой частью».

3 голосов
/ 30 апреля 2009

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

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

Еще одним преимуществом использования MVC является то, что вы, как правило, не усложняете обслуживание приложения для того, кто идет за вами, если вы не придерживаетесь многоуровневой работы. Это потому, что теперь у вас есть заранее определенное место для размещения любого аспекта реализации новой функции.

Что касается жесткой связи, вы не сможете реализовать функцию, если между слоями не будет связи. Слабая связь не означает, что слои не знают друг друга полностью - это означает, что уровень должен не знать, как реализованы другие уровни. Например: уровень контроллера не имеет значения, используете ли вы базу данных SQL или просто пишете двоичные файлы для сохранения данных на уровне доступа к данным, просто существует уровень доступа к данным, который может получать и хранить объекты модели для него. Он также не заботится о том, используете ли вы сырой PHP или Smarty на уровне представления, просто он должен сделать некоторый объект доступным под некоторыми заранее заданными для него именами. В то время как слою представления даже не нужно знать, что существует слой контроллера - он вызывается только с данными для отображения в готовом виде под вышеуказанными именами, предоставленными /something/.

1 голос
/ 30 апреля 2009

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

Когда люди впервые начинают разрабатывать PHP-приложения, код обычно представляет собой один большой беспорядок. Логика представления смешивается с бизнес-логикой, которая смешивается с логикой базы данных. Следующий шаг, который обычно делают люди, - это начать использовать какой-то шаблонный подход. Неважно, использует ли это специализированный язык шаблонов, такой как smarty, или просто выделяет разметку презентации в отдельный файл.

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

Все это кажется очень естественным для меня, и я не считаю, что это очень спорно. Но на данный момент вы в основном уже используете подход MVC. Все, что за этим стоит, - это просто более или менее изощренные попытки устранить необходимость переписывать часто используемый код.

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

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

0 голосов
/ 01 мая 2009

Ах ... старые добрые аргументы MVC.

Мне нужно поддерживать многогранное PHP-приложение, части которого написаны в стиле «MVC», но не все. Хуже того, разные части имеют разные способы создания MVC, все из которых являются доморощенными. А некоторые страницы просто делают все сами.

Основная проблема не в том, что в коде фреймворка есть различия, а в том, что кодеры явно не понимают, как абстрагировать API. IMO, это самая большая проблема с MVC-фреймворками. Почти весь код, с которым мне приходится работать, использует "модели" в качестве мест для размещения функций. Это кошмар в обслуживании.

Чтобы сделать это поддерживаемым, IME вам нужно несколько вещей:

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

    Я не хотел бы использовать термин «модель» для этого, потому что это спорный. Что бы ни вызывало этот уровень, не должно заботиться о том, как хранятся данные, не должно даже беспокоиться о таких вещах, как дескрипторы базы данных: это all работа уровня доступа к данным.

  • Диспетчер, который очень легок и не совершает никакой магии, кроме просто отправки.

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

(Хорошо, разглагольствовать ...)

Отсутствие PHP в применении фреймворка означает, что лучшие фреймворки делают то, что делает PHP: они остаются в стороне. Некоторые из наиболее поддерживаемых кодов, над которыми я работал, имели один оператор require() вверху, выполняли все манипуляции с данными с объектами данных (SQL не виден), затем выводили HTML, окруженный функциями шаблона, с контролем формы сделано с помощью согласованной функции API.

0 голосов
/ 01 мая 2009

Code Igniter и Kohana (потомок CI) в порядке, но также слабо MVC. Мне нравится простой PHP-фреймворк . Это не мешает вам и обеспечивает важные вещи, без навязывания вам структуры или сложных соглашений.

0 голосов
/ 30 апреля 2009

Вы можете попробовать код Igniter. Его очень легко выучить, и он не принимает строго MVC, в то же время давая вашему коду хорошую структуру.

0 голосов
/ 30 апреля 2009

Zend Framework очень слабо связан и очень хорош. Проверьте это:

http://framework.zend.com

Эта статья может быть также полезна:

http://blog.fedecarg.com/2009/02/22/zend-framework-the-cost-of-flexibility-is-complexity/

0 голосов
/ 30 апреля 2009

Тот факт, что вам нужно создать новое Действие модели и контроллера, когда вам нужна новая страница, я не думаю, означает, что ваши слои M, V и C тесно связаны. Это просто разделение интересов и способствует развязке системы.

Тем не менее, вполне возможно по-королевски испортить замысел MVC (и я работал над таким приложением) и сделать так, чтобы компоненты были тесно связаны. Например, сайт может поместить «движок рендеринга» непосредственно на уровне контроллера. Это, очевидно, добавит больше связи. Вместо этого будет разработан хороший MVC, чтобы контроллер знал только имя используемого представления и затем передавал это имя в отдельный механизм рендеринга.

Другой пример плохого дизайна в MVC - это когда в представлениях жестко запрограммированы URL-адреса. Это работа движка маршрутизации. Представление должно знать только о действии, которое необходимо вызвать, и о параметре, в котором это действие необходимо. Затем механизм маршрутизации предоставит правильный URL.

...