BaseModel в PHP MVC, хороший или плохой?

Question

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

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

Атомные рамки MVC имеют «BaseModel». Я читал, что на самом деле это плохая практика, потому что «Модель» не следует рассматривать как другой класс. Но как настоящий «слой», который может содержать такие вещи, как шаблон «mapper» или «репозиторий» и т. Д.

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

я могу просто сделать что-то вроде:

class User extends BaseModel 
{ 
    // the GetUserBy* could easily be something that's handled by the 
    // BaseModel class, like in the Repo pattern. 

    public function getUserByName ($name) 
    { 
     // no error handling of any kind, just for simplicity 
     return $this->db->exec("SELECT * FROM users WHERE name='".$name."'"); 
    } 

    // $data = array 
    public function saveUser ($data) 
    { 
     // Make sure no extra fields are added to the array 
     $user = array ('name' => $data['name'], 
         'address' => $data['address']); 

     $this->db->autoSave ($user); 
    } 
} 

Но если я бы пойти на хранилище шаблон, то я должен создать следующие: Хранилища Entities DAO

образований заполнителей другие репозитории. Поэтому в основном я вручную выписываю всю схему базы данных для объектов ...

В конце концов, какая разница? За исключением того, что я, вероятно, мог бы сэкономить много времени, просто используя класс BaseModel ...

Но почему это все еще считается плохой? Дело не в том, что шаблон репо отделяет мое приложение больше, чем я делаю сейчас. Потому что для меня эти шаблоны, упомянутые выше, кажутся очень завышенными. Вероятно, он работает только в приложении, имеющем общее состояние; Сохранять объекты локально (в репозитории) и позднее их передавать.

Вот почему я думаю, что никто не может реально ответить на этот вопрос ...

Но я все еще надеясь увидеть достойный ответ, который заставляет меня идти: «Ааааа ... Что я думал .... ». Но если нет, то я уверен в моем случае, что BaseModel - это совсем не плохо, и что большинство блоггеров - всего лишь кучка овец :-)

Answer 1

Это не то, что картина репо разъединяет мое приложение более я делает сейчас

Ваше приложение тесно связан с компонентами базы данных SQL (которые, по сути, действуют в качестве картографа) , Однако, несмотря на это, ваш дизайн гораздо больше похож на Repository, чем на подход Active Record (что, скорее всего, связано с тем, что большинство этих блоггеров вы называете).

Активные записи инкапсулировать не только данные, но и доступ к базе данных:

$user = new User(); 
$user->setUsername('jane'); 
$user->setEmail('jane@foo.bar'); 
$user->save(); 

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

class UserRepo extends BaseRepo 
{ 
    // user-specific repo code... 
} 

$userRepo = $this->getRepo('User'); 
$user = $userRepo->getUserByName('jane'); 
$user['email'] = 'jane@new.email'; 
$userRepo->save($user); 

Нет ничего плохого в том, что у вас базовое репо.

Answer 2

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

Answer 3

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

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

Answer 4

Если вы пытаетесь изучить хорошие методы MVC из фреймворков PHP, то вы делаете это неправильно. Даже лучшие фреймворки в PHP пронизаны ошибками дизайна и недостатками.

Структуры, которые имеют «BaseModel», как правило, реализуют своего рода ORM. И самый популярный шаблон здесь - ActiveRecord. Это хорошо для простых таблиц, без каких-либо отношений с другими (в основном - прославленные геттеры/сеттеры). Но начинает разрушаться при работе с более сложными структурами и запросами. Обычно вызывает обширные technical debt.

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

И нет, «кучка блоггеров» не овец. Они просто прочитали книги о архитектуре приложений и объектно-ориентированном программировании. Когда вы в последний раз читали книгу на эту тему?