Должны ли модели MVC быть статичными?

Question

Должны ли модели MVC быть статичными?

РЕДАКТИРОВАТЬПосле некоторых исследований я увидел эту структуру: это MVC рамки. У него есть классы в папке Libs, которые являются статическими (например, Config, Session), я могу использовать их?

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

У меня есть много моделей, таких как DB, User, Config и т. Д., Но я использую многие из них в каждой создаваемой мной функции.

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

Проблема в том, что после создания базовых моделей я получил такой код (внутри контроллера).

class User
{
function signup($username, $password, ...)
{
$config = new Config();
$DB       = new DB();
$HTML     = new Session();
// And so on...

$canRegister = $config->get("registration-enabled");
if ($canRegister and ..) {
$this->username = $username;
$DB->saveAccount($this);
$session->setUser($this);
} else {
throw new Exception('bad signup');
}
}
}

Я должен создать экземпляры многих моделей только для одной или двух функций … но если модели статичны, это должно выглядеть так:

class User
{
function signup($username, $password, ...)
{
$canRegister = Config::get("registration-enabled");
if ($canRegister and ..) {
$this->username = $username;
DB::saveAccount($this);
session::setUser($this);
} else {
throw new Exception('bad signup');
}
}
}

Обратите внимание, что во многих моделях не используется метод __construct. Так хорошо ли (или не плохо) иметь статические модели в шаблоне MVC?

Пожалуйста, см. РЕДАКТИРОВАТЬ выше, прежде чем ответить.

0

model-view-controller php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Модель это понятие абстракции!

Модель состоит из Сервисы, в то время как сами сервисы состоят из абстракций хранилища и объектов, которые обрабатывают вычисления. Проще говоря, сервис — это мост между объектами домена и абстракциями хранилища (например, Data Mappers или Table Gateways). Модель состоит из этих услуг.

Это типичный способ структурирования модели:

  Model
- Storage
- MySQL
- YourMapper
- Service
- YourService

Класс, который обрабатывает абстракцию к таблице и выполняет вычисления и проверку, также известен Анемическая модель (что, кажется, ваш случай), потому что это нарушает SRP и нарушает разделение проблем.

Придерживаясь этого право Кстати, вы можете легко заменить хранилище (скажем, вы можете заменить MySQL на MongoDB), поскольку они больше не связаны с бизнес-логикой. Или вы можете заменить доменные объекты, которые обрабатывают вычисления, даже не касаясь хранилища.

И нет, ничто не должно быть статичным!

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

class Uploader
{
...

public function upload(array $files)
{
$path = Config::read('upload_path');
$some_another_option = Config::read('foo');

$this->move($path, $some_another_option, $files);
}

...
}

Так что за проблема может лежать здесь? Просто помните, что мы пишем библиотеку, и давайте посмотрим правде в глаза:

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

Да, вы, вероятно, видели этот подход в других рамках. Но популярность не значит правильно, во всяком случае.

Правильный путь,

Вы должны помнить, что создание объектов — это еще одна обязанность. Когда вы создаете Conifg вы, вероятно, загружаете данные откуда-то (массив или таблица, что угодно). Таким образом, в вашем первом подходе вы должны загрузить его n-times? Это кажется очень неправильным способом.

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

$config = new Conifg();
$config->load(__DIR__ . '/config_array.php');$user = new User($config);

$system = new System($config);

// and so on, you got the point

То же самое относится к вашему DB а также Session, Классы, которые используют эти объекты, не должны беспокоиться об их создании. Они просто должны беспокоиться о том, как их использовать.

Помните: Ничто так не убивает способность повторного использования кода, как статические классы и синглтоны

Все крутые парни называют эту технику Внедрение зависимости

4