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

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

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

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

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

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

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

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

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

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

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

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

Подумайте об отношениях, таких как интерфейсы или контракты между части приложения. Модель обещает сделать эти данные доступными для представления и контроллера. Никому нет дела до , как Модель делает это. Он может читать и писать из типичной СУБД, такой как 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';
    }
}

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

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

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

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

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

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

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

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

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

http://framework.zend.com

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

http://blog.fedecarg.com/2009/02/22/zend-framework- цена-гибкость-сложность /

The fact that you have to create a new Model and Controller Action when you need a new page I don't think means that your M, V, and C layers are tightly coupled. This is just the separation of concerns and contributes to a decoupled system.

That said, it is quite possible to royally screw up the intent of MVC (and I've worked on an app like this) and make it make the components tightly coupled. For instance, a site might put the 'rendering engine' directly in the Controller layer. This would obviously add more coupling. Instead a good MVC will be designed so that the controller is only aware of the name of the view to use and then pass that name to the separate rendering engine.

Another example of bad design in an MVC is when the views have URLs hard-coded into them. This is the job of the Routing engine. The view should only be aware of the action that needs to be called and the parameter that action needs. The Routing engine will then provide the correct URL.

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