Нужно ли создавать класс для объектов?

Question

[Алексей]

Всем привет! Вопрос по большей части по MVC... Как правило, везде описывают MVC как Model Controller и View. Но я встречал, что создают дополнительную папку в проекте "Entity", где хранят классы для объектов.
Т.е. например при получении списка постов из базы данных делается что-то вроде:

class Post{
	private $title, $text, $owner_id, $category, $date, $likes, $dislikes; // ........ и т.д.
	
	function __construct($id){ $this->id	= $id;}
	
	function setTitle($title){ $this->title = $title;}
	function setText($text){ $this->text = $text;}
	
	// И так 100500 сетеров и гетеров для установки и получения каждого свойства
}

class ModelPost{
	
	private $list_posts;

	function getPostsFromId($ids){
		
		$res = mysql_query("SELECT * FROM `posts` WHERE `id` IN($ids)");
		while($row = mysql_fetch_assoc($res)){
			
			$post = new Post($id);
			$post->setTitle($row['title']);
			$post->setText($row['text']);
			
			$this->list_posts[$row['id']] = $post;
		}

		return $this->list_posts;
	}
}

Это правильный подход, или я опять что-то не так понял?

Answer 1

[Stalker_RED]

Почти все современные реализации MVC довольно далеки от "канонических". Особенно в вэб.

https://habrahabr.ru/post/321050/

UPD: и вообще, вам не кажется, что вы изобретаете собственную реализацию ORM?
Они готовые уже есть. Doctrine, например.

Answer 2

[Егор]

Подход set - get часто используется, но как по мне - это мрак. Если 100 свойств у класса - должно быть 100 get, и 100 set.

В данном случае я бы все свойства post установил бы через конструктор. А доступ и модификацию к ним сделал бы через магические методы.

Comments

[dmitriy]

все свойства через консруктор? даже необязательные, ну вы даете?!

[Егор]

А если свойств действительно 100 - то разделить их на разные объекты. Общее кол-во свойств лучше чтобы было 3-4. Если больше - логически разделять на разные объекты.

[Егор]

Папка Entity и используется для того, чтобы хранить такие сущности. Контроллер - руководит логикой программы, модель - извлечением и сохранением, library - сервисы (обработчики данных).

[Алексей]

Егор, Зачем разделять? Прийдется же в каждом писать свои гетеры и сетеры? Не улавливаю преимущества... Поясните плз

[Егор]

diamond, уточните что имеете ввиду под "необязательными".

[Егор]

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

[dmitriy]

например

class User{
protected $email;
protected $lastAuthDate;
function __construct($email){
$this->email = $email;
}
}

lastAuthDate - здесь не обязательное свойство для создания объекта, дата последней авторизации, то есть пользователь может быть зарегистрирован, но не воспользуется авторизации на сайте
email - обязательность , нельзя создать объект без данного свойства

п.с. id - кстати не является обязательным тоже, так как новый объект (не сохраненный) не имеет id в системе

[dmitriy]

Егор ваш IDE будет бесполезен, работа с таким кодом усложнится

[Егор]

diamond,

abstract class Entity
{
    public function __get($property)
    {
        if (!property_exists($this, $property)) {
            throw new \Exception('');
        }
        return $this->$property;
    }
}

/**
 * Class User
 * @property Email $email
 */
class User extends Entity
{
    protected $email;
    public function __construct(Email $email)
    {
        $this->email = $email;
    }
}

/**
 * Class AuthorizedUser
 * @property User $user
 * @property DateTime $lastAuthDate
 *
 */
class AuthorizedUser extends Entity
{
    protected $user;
    protected $lastAuthDate;

    public function __construct(User $user, DateTime $lastAuthDate)
    {
        $this->user = $user;
        $this->lastAuthDate = $lastAuthDate;
    }
}

[Егор]

kruslan,
>Лишились автокомплита
С автокомплитом в моем PhpStrom все ок даже если использовать магические методы.

> валидаторов, фильтров и пр.
Не понял почему я лишусь валидаторов, фильтров, и пр.

>Плюс, сильное замедление приложения.
Сравнительный тест в студию!
Только не показывайте извлечение 1млн. сущностей, пожалуйста.

[Егор]

kruslan,
>тогда уж лучше через отдельный метод типа init или setProperties. Конструктор для других целей.
Для каких это других? Что еще использовать в конструторе, если не задание необходимых свойств?

[Егор]

diamond,
>ваш IDE будет бесполезен
Как написал выше c PhpStrom все нормально, автокомплит работает.

>работа с таким кодом усложнится
За счет чего?

[dmitriy]

за счет документирования кода да, можно обеспечить подсветку свойств, но документацию нужно поддерживать,
также нельзя использовать валидацию и цепочку вызовов
$user->setEmail($email)->setDateTime($date);

[Егор]

diamond,
>за счет документирования кода да, можно обеспечить подсветку свойств, но документацию нужно поддерживать
А поддерживать получение свойств через get не нужно? И что здесь поддерживать? Один раз написал - и получил подсветку свойств.

>также нельзя использовать валидацию и цепочку вызовов
Почему валидацию использовать нельзя?
А при дизайне объектов с "цепочкой" вызова, как говорится "кто что видит":
Кто-то видит готовое изделие, когда нужно взять большой кусок чего-то, чуть отрезать, чуть отпилить, чуть подправить.
А кто-то видит УЖЕ готовое изделие. User-а нельзя "пилит" и "править", чтобы он наконец получился. Он ЕСТЬ User.

[dmitriy]

1. программисты пишут/изменяю код. пишут тесты для этого кода, но не всегда актуализируют документацию. Поэтому разработка ухудшается когда IDE вам подсказывает о наличие свойства а по факту его нет.
2. Гетеры предоставляют скрытие реализации, наружу торчит метод getEmail() а внутри класса вы можете делать кучу пробразований, рефакторить код, но это останется внутри черного ящика.
Внешний код как был настроен на getEmail() так и остался.
я представляю код завязанный на $user->email не получится просто взять и отрефакторить
3. через сеттеры, можно делать валидацию, как писали выше, это удобно https://stackoverflow.com/questions/15209511/best-...
в вашем случае модель может ходить с некорректными данным по приложению
4. вот давайте подсчитаем минусов который дает ваш подход, все из за чего что будут реализованы 100 не нужных сеттеров и геттеров, просто может пересмотреть дизайн класса если у него столько свойств?

[Егор]

diamond,
>1. Поэтому разработка ухудшается когда IDE вам подсказывает о наличие свойства а по факту его нет.
Т.е. код переписать не забыли, а изменить свойство - забыли. Не лучше просто свойство дописать/переписать вместо кода доступа к свойству. Код УЖЕ написан для всех свойств.

>2. Гетеры предоставляют скрытие реализации, ...
а без геттеров нет сокрытия реализации?

>Внешний код как был настроен на getEmail() так и остался.
А $user->email нужно будет изменять?

>я представляю код завязанный на $user->email не получится просто взять и отрефакторить
Это почему же?

>3. через сеттеры, можно делать валидацию, как писали выше, это удобно ... в вашем случае модель может ходить с некорректными данным по приложению
Валидацию нужно делать не через setter-ы, а там, где создается объект. Например для email - при создании email. Потому что это ЕСТЬ email.
Например:

class Email{
    protected $email;
    public function __construct(string $email)
    {
        if (false === $this->isValidEmail($email)) {
            throw new Exception('Указан не корректный email');
        }
        $this->email = $email;
    }

    public function __toString()
    {
        return $this->email;
    }

    protected function isValidEmail(string $email): bool
    {
        // валидируем.
    }
}

Не оно? Плохо? Трудно валидировать?

[dmitriy]

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

[Александр]

diamond, Егор, Мде... развели тут срач не пойми о чем. То что написал автор коммента уже давно реализовано в Yii2 и прекрасно работает.

[Егор]

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

[dmitriy]

хотелось бы увидеть аналогичный алгоритм для сравнения в вашей архитектуре

<?php
//Entity
class Entity{
    
    use ObjectToArrayTrait;
    
    protected $id;
    
    public function setId($id){
        $this->id = $id;
        return $this;
    }
    public function getId(){
        return $this->id;
    }
}

//Validation
class UserValidation extend Validation{
    
    protected $user;
    
    public function __construct(User $user){
        $this->user = $user;
    }
    
    public function isValid(){
        //validation logic
        return true
    }
    
}

//User
class User extends Entity
{
    protected $email;
    protected $name;
    public function __construct(Email $email, $name)
    {
        $this
            ->setEmail($email)
            ->setName($name);
    }
    //даже если изменим через свойство другой класс не пройдет
    public function setEmail(Email $email){
        $this->email = $email;
        return $this;
    }
    public function setName($name){
        $this->name = $name;
        return $this;
    }
    public function getEmail(){
        return $this->email;
    }
    public function getName(){
        return $this->name;
    }    
}
//UserRepo
class UserRepo{
    protected $db;
    function __construct(ActiveRecord $db){
        $this->db = $db;
    }
    //получаем User
    public function getUserById($id){
        $row = $this->db->getRow("users")->where("id",$id);
        $user 
            = (new User(new Email($row["email"])))
            ->setName($row["name"]);
        return $user;
    }
    //сохраняем
    public function save(User $user){
        if($user->getId()>0){
            $this->db->update("users",$user->toArray())->where("id",$user->getId());
        }
        else{
            $this->db->insert("users",$user->toArray());
        }
    }
}


//принимаем пост
$post = $request->all();
//создаем объект
$user = (new User(new Email($post["email"])))->setName($post["name"]);
//валидируем
$validation = new UserValidation($user);
//сохраняем
if(!$validation->isValid()){
    throw new ValidationError($validation->getErrors());
}
else{
    $userRepo->save($user);
}

[Егор]

Если логика клиентского кода предполагает сохранение данных о новом юзере, тогда клиентский код я бы сделал таким (try-catch и другие детали в примере опускаю, чтобы не осложнять):
// Очищенные данные из $_POST
$form_data = (new Request())->post();

// Пользователь, у которого уже все внутри валидировано.
// Мне не нужно беспокоиться о том, что внутри что-то не так, email не такой, и т.д.
$user = new User($form_data['name'], new Email($form_data['email']);

// Это уже сохраненный юзер.
// Отличие от User - у него есть id, и он точно сохранен в БД.
$db_user = new DbUser($user);

А в вашем случае вначале создается некое "тело" с email. Затем вы добавляете в него что-то. Потом еще что-то и т.д. А потом проверяете: это все еще "Тело" или уже "Человек" ? А, ну если "Человек" - тогда сохраняем.
Отличие в том, что у вас процесс. А у меня - реальные сущности.

[Егор]

diamond, Если логика клиентского кода предполагает сохранение данных о новом юзере, тогда клиентский код я бы сделал таким (try-catch и другие детали в примере опускаю, чтобы не осложнять):

// Очищенные данные из $_POST
$form_data = (new Request())->post();

// Пользователь, у которого уже все внутри валидировано. 
// Мне не нужно беспокоиться о том, что внутри что-то не так, email не такой, и т.д. 
$user = new User($form_data['name'], new Email($form_data['email']);

// Это уже сохраненный юзер. 
// Отличие от User - у него есть id, и он точно сохранен в БД.
$db_user = new DbUser($user);

А в вашем случае вначале создается некое "тело" с email. Затем вы добавляете в него что-то. Потом еще что-то и т.д. А потом проверяете: это все еще "Тело" или уже "Человек" ? А, ну если "Человек" - тогда сохраняем.
Отличие в том, что у вас процесс, а у меня - "живые" сущности.
Когда есть процесс - его нужно знать (т.е. читать мануалы). А у меня - процесс весь "зашит" внтури. мне остается лишь знать какой объект мне нужен и все.

Я не смогу сделать так:
$user = new User(new Email($post["email"]))->set ... эмм... мне что-то set делать надо? А пройдет ли потом валидация без какого-то set?

[Алексей]

Егор, diamond, судя по вашей дискуссии, я понял, что вроде я делаю все правильно? по крайней мере двигаюсь в нужную сторону ))

Но получается такая ситуация, что у сущности Post есть свойство author_id, которое мы также получаем в ModelPost.
Но по-хорошему, мне ведь нужно отдать данные об авторе, во View, тоже как объект? Т.е. свойство author_id должно быть объектом author в котором присутствует id, имя автора, аватар и т.д.. На каком этапе нужно получать с помощью author_id информацию об авторе поста?

Полагаю, что удобно было бы в классе Post создать метод Post->GetAuthor($author_id), в котором было бы обращение к методу модели ModelUser ModelUser->getUserFromId($id) там по такому же принципу, как я создал сущность Post, создастся сущность User, вернется в Post и сохранится в Post->author. Вроде красиво, но мне кажется не правильно.
Потому как мы же получаем много постов на страницу, а значит выйдет так, что для каждого запроса будет лететь запрос в базу для получения User.

Поэтому, я догадываюсь, что это лучше сделать так:
При вызове модели ModelPost где-то указать, что когда мы будем получать посты, нужно к ним получить еще и авторов. А значит после выполнения цикла while($row = $res->fetch_assoc()){...} создать такой код:

if($this->needAuthorsObjects){
	// этот метод переберет весь $this->list_posts и достанет все id авторов
	$authors_id = $this->getIdAuthorsFromPosts();
	
	// получаем массив объектов User
	$users = new ModelUser->getUserFromId($authors_id);

	// перебираем массив постов и добавляем к нужномупосту соотвествующего автора
	foreach($this->list_posts as $post_obj){
		$post_obj->setAuthor($users[$post_obj->id]);
	}
}

Правильно?

[dmitriy]

все что вы делаете уже есть в ORM, посмотрите Propel2
просто вы наткнетесь на кучу проблем если будете реализовывать самостоятельно.

[Алексей]

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

[dmitriy]

Но по-хорошему, мне ведь нужно отдать данные об авторе, во View, тоже как объект? Т.е. свойство author_id должно быть объектом author в котором присутствует id, имя автора, аватар и т.д.. На каком этапе нужно получать с помощью author_id информацию об авторе поста?

два варианта либо получить все иерархию объектов сразу либо lazy load лениво,
1. вы получаете $post как объект, $post->getAuthor() //вытащит объект автора без доп.запроса
2. линиво при обращении к методу $post->getAuthor() будет сделан запрос на получение объекта Author
ОРМ умеют работать в двух вариантх

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

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

Answer 3

[dmitriy]

класс Post - нормально
ModelPost - это Repository а не модель

Comments

[Алексей]

А что не так с ModelPost?

[dmitriy]

какую функцию выполняет?

[Егор]

diamond, Model, Repository, ... В чем принципиальная разница?

[dmitriy]

Модель - это понятие в рамках MVC
модель можно разложить по классам Entity, Repository, Agregate, DataMapper и тд

[Егор]

diamond, откуда взяли классификацию моделей? Это стандарт какой-то?

[dmitriy]

zendframework.ru/forum/index.php?topic=6083.0

[FilippQoma]

Егор, это устоявшиеся термины паттернов проектирования слоев модели и persisting модели

Answer 4

[Заур Ашурбеков]

Вот как я всё это понимаю:
Entity это класс для работы с БД или другим хранилищем данных. Его задача заключается именно в предоставлении удобного интерфейса для работы с этим хранилищем для конкретно этой "структуре данных".

Model это класс, с которым работает весь окружающий код. Он должен быть удобным для работы с этой моделью данных. Его интерфейс никак не зависит от того, как именно хранятся данные и описывает только поведение этой модели. Модель это ведь не только запись/чтение данных, там достаточно много своих задач. А вот для записи/чтения данных внутри Modelи уже происходит работа с Entity. И если вдруг вы решили менять БД с какой-нибудь SQL на noSQL, сделать некоторые правки в работе с БД или т.п., то вы просто изменяете Entity класс, не влезая в логику модели или, упаси Боже, в бизнес-логику.

Проще говоря задача Entity работать с БД, задача Modelи - описывать поведение модели. Для хранения и получения данных в Модели используется Entity.

Что касается правильного подхода: если у вас проект небольшой и вам не нужно городить тонны кода для работы моделей (а-ля блог), то вся эта канитель с Entity пустая трата времени. Если же проект серьёзный, с последующей долгой поддержкой, то такое разделение логики сохранит множество нервов всей команде разработчиков.

И напоследок знаменитая статья дяди Боба о чистой архитектуре

Comments

[dmitriy]

Entity это класс для работы с БД или другим хранилищем данных.

перешел по ссылке, первое что написано про сущности (Entity)
Сущности определяются бизнес-правилами предприятия.

в вашем случае сущность завязана на работу с бд, зависит от инфраструктуры, в идеале сущности не важно с каким источником данных она связанна, седня БД, завтра мемкеш, сессия, сервис
почитайте про DDD, code first

Answer 5

[synapse_people]

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

Answer 6

[Алексей Васильевич]

Тут уже много написано (в т.ч. и в комментариях). Но почему-то никто не упомянул про DDD (Domain Driven Development). "Ноги" эти entity растут как раз оттуда. Если в двух словах, то классы сущностей вам нужны, чтобы абстрагироваться от источника этих самых данных. Эту entity вы можете перетаскивать на любой фреймворк (или вообще на голом PHP) - она не пострадает

Comments

[Алексей]

А что должен "уметь" делать Entity? Понятно, "set", "get" параметров, возвращать некие комбинации этих параметров вроде:

getStringAddress() {return $this->country.', '.$this->state.', '.$this->city}

(но тут не уверен)... В базу данных он лезть не должен, трогать другие классы также не должен...
Можете ли вкратце описать, или это и есть максимум того, что на Entity можно возлагать?

[Алексей Васильевич]

Кроме get/set - ничего )) В этом его прелесть: это абсолютно самодостаточная, атомарная единица проекта. Вся движуха с выборкой/сохранением в БД, валидацией и т.д. начинается на следующем уровене (моделей, репозиториев, сервисов, контроллеров и т.д.)

В такой ситуации вы можете таскать сущности по проектам, не заморачиваясь. Например, запилить backend на Yii2, а API - на Slim-е. Пример синтетический, но, надеюсь, понятный)

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

Answer 7

[Дон Ган]

В данном примере Post - это по факту модель.
А ModelPost - это реализация паттерна DataMapper - прослойка между обьектами и базой.

В любом случае - подход правильный.