альтернатива MVC, которая слабо связана?

Question

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

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

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

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

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

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

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

EDIT:

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

Как шаблоны шаблонов, я считаю, что шаблон MVC является одним из самых «слабо связанных» способов построения приложения.

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

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

View предполагает, что модели и контроллеры будут выполнять свои обещания и затем могут быть разработаны в вакууме. Модели и контроллеру не волнует, генерирует ли представление 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, вы можете передать им только взгляды и сказать «работа над этой частью».

Answer 4

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

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

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

Answer 5

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

http://framework.zend.com

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

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

Answer 6

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

Answer 7

Код Igniter и Kohana (потомки CI) в порядке, но также свободно MVC. Мне нравится simple php framework. Это не мешает вам, и это обеспечивает важные вещи, не вызывая на вас структуру или сложные соглашения.

Answer 8

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

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

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

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

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

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

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

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

(Хорошо, разглагольствовать над ...) отсутствие

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