-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Фреймворки
- Автор темы AllReady
- Дата начала
Вурдалак
Продвинутый новичок
Да, но там вроде бы в скобках даются оригинальные названия. Я даже не помню какие там названия были на русском.
Впрочем, я не спорю, оригинал было бы лучше. Ubiquitous language среди программистов. А то вот тут был чувак, который говорил «сводный корень». Я не сразу понял о чём он.
AllReady
Новичок
Только на этом форуме, мне объясняют досканально. Недавно в группе: https://vk.com/echo_php , а так же на тостере - я задавал вопросы про mvc и мое представление о модели. Спрашивал у моего брата (он сениор питон разработчик по его словам, но он действительно хорошо знает c++, python и работает сейчас в хорошей компании старшим программистом. но как он говорит, ему сейчас любой язык легко дается. Вот он мне и сказал про то, что модель работает с БД) Всегда соглашаются, из чего я и продолжаю изучение в этом направлении. Теперь когда я пишу как понимаю, меня тут поправляют, что нигде не происходит.
Я уже действительно не соображаю, как понимать модель. Если можно, объясните пожалуйста на одном из примеров: у меня есть обычный чат. Поля: id, user_id, message, time_add. Есть у меня модель Chat, которая наследуется от Model. Какие основные методы должен содержать класс, кроме основных: вставка, удаление и обновление сообщений. Зачем в модели хранить поля с таблицы ? Зачем если их храним, делать некоторые приватными. Мы же и так не получим эти приватные свойства, если сами не создадим метод который дает нам информацию по этим полям. Честно, про ООП я читал МНОГО раз. Но применять я его так и не научился.
На примере игры, я еще как то понимаю. У объекта есть свой логин, свои жизни, своя защита, координаты и т.д.. Но в php зачем в модели хранить например поля с таблицы..
Я прошу прощения у тех, кому я выношу мозг этой темой. Я не могу никак понять правильное понятие модели в php из-за того, что я распросил 5-6 форумов и только тут мне стало интересно рассмотреть её подробней. Но я очень хочу и рассчитываю, что именно здесь я правильно пойму ее и буду продвигаться дальше.
Я уже действительно не соображаю, как понимать модель. Если можно, объясните пожалуйста на одном из примеров: у меня есть обычный чат. Поля: id, user_id, message, time_add. Есть у меня модель Chat, которая наследуется от Model. Какие основные методы должен содержать класс, кроме основных: вставка, удаление и обновление сообщений. Зачем в модели хранить поля с таблицы ? Зачем если их храним, делать некоторые приватными. Мы же и так не получим эти приватные свойства, если сами не создадим метод который дает нам информацию по этим полям. Честно, про ООП я читал МНОГО раз. Но применять я его так и не научился.
На примере игры, я еще как то понимаю. У объекта есть свой логин, свои жизни, своя защита, координаты и т.д.. Но в php зачем в модели хранить например поля с таблицы..
Я прошу прощения у тех, кому я выношу мозг этой темой. Я не могу никак понять правильное понятие модели в php из-за того, что я распросил 5-6 форумов и только тут мне стало интересно рассмотреть её подробней. Но я очень хочу и рассчитываю, что именно здесь я правильно пойму ее и буду продвигаться дальше.
Последнее редактирование:
@AllReady, с комментариями у тебя есть по крайней мере две задачи:
1) дать остальному приложению методы для вставки, редактирования, удаления и т.д. комментариев
2) хранить эти комментарии в базе(вот для этой задачи вполне нормально знать о колонках в базе).
По мне так совершенно нормально по классу на каждую эту задачу.
Для 2) есть ORM Eloquent. Она хорошо справится с этой задачей. Посмотри документацию или примеры. с Английским у тебя как?
Для 1)... во многих примерах прямо в контроллерах фигачат работу с Eloquent классом... мне не нравится. Я делаю отдельный класс для этого(сказать по честному, я стал делать классы для каждого действия. Т.е. есть класс CommentCreator например и он будет вставлять комментарии... но ты пока об этом не думай). Можешь и в контроллерах прямо конешн... для началу нормально. Тут главное начать. Потом потихоньку дойдешь.
1) дать остальному приложению методы для вставки, редактирования, удаления и т.д. комментариев
2) хранить эти комментарии в базе(вот для этой задачи вполне нормально знать о колонках в базе).
По мне так совершенно нормально по классу на каждую эту задачу.
Для 2) есть ORM Eloquent. Она хорошо справится с этой задачей. Посмотри документацию или примеры. с Английским у тебя как?
Для 1)... во многих примерах прямо в контроллерах фигачат работу с Eloquent классом... мне не нравится. Я делаю отдельный класс для этого(сказать по честному, я стал делать классы для каждого действия. Т.е. есть класс CommentCreator например и он будет вставлять комментарии... но ты пока об этом не думай). Можешь и в контроллерах прямо конешн... для началу нормально. Тут главное начать. Потом потихоньку дойдешь.
-- Типа, теория:
1. Модель — это объект, своими свойствами описывающий предмет моделирования. Источник этих данных может быть любой: Это может быть запись в БД, а может и не быть. Это может быть файл. Или просто структура в памяти. Или даже случайные значения.
2. Модель может представлять не только сведения об объекте моделирования, но и способы их изменения (заполнения, фильтрования, и тд)
Если брать твой пример: представь модель, которая содержит информацию об одном Сообщении в чате: у нее есть несколько однозначных критериев, автор, дата, и текст. То, что в ТЕХНИЧЕСКИ, в КОНКРЕТНОЙ РЕАЛИЗАЦИИ модели эти данные хранятся в РСУБД в какой-то табличке, у которой поля называются user_id, message, и time_add — для понимания модели вообще не важно.
3. Если предположить, что другими сущностями, которые ты моделируешь, являются например, Пользователь и Разговор, то становится понятно, что модель Сообщения может иметь метод, который например, вернет модель с предствлением Пользователя, который связан с этим сообщением. Это называется связью один-к-одному.
4. Модель Разговор может содержать в себе информацию обо всех Сообщениях, произошедших в рамках Разговора. Это связь один-к-многим. И например, иметь метод, позволяющий получить набор из последних 10 сообщений. Или отфильтровать их по Пользователю.
-- Типа, реальность
5. Когда в КОНКРЕТНОЙ технической реализации моделей используется реляционная база данных, возникает очевидная проблема: объектные структуры и их связи плохо и сложно представляются через набор линейных таблиц. Поэтому существуют ORM (Объектно-Реляционное Отображение) — попытка технически обойти эти ограничения, и дать возможность выбирать реляционные линейные данные в объектное представление, и сохранять обратно изменения.
6. Один из вариантов ORM называется AR (Active Record), это самая примитивная реализация ORM, в которой проблема решается таким подходом, что каждая Модель описывает одну строку или набор строк в реальной таблице БД, и связи с другими таблицами. Это самый ПРИМИТИВНЫЙ, ТЕХНИЧЕСКИ ПРОСТО РЕАЛИЗУЕМЫЙ и наиболее легко автоматизируемый способ реализации ORM, и оттого — самый распостраненный. Но по этой же причине он хуже всего соотносится с пониманием того, как взаимодействуют модели.
1. Модель — это объект, своими свойствами описывающий предмет моделирования. Источник этих данных может быть любой: Это может быть запись в БД, а может и не быть. Это может быть файл. Или просто структура в памяти. Или даже случайные значения.
2. Модель может представлять не только сведения об объекте моделирования, но и способы их изменения (заполнения, фильтрования, и тд)
Если брать твой пример: представь модель, которая содержит информацию об одном Сообщении в чате: у нее есть несколько однозначных критериев, автор, дата, и текст. То, что в ТЕХНИЧЕСКИ, в КОНКРЕТНОЙ РЕАЛИЗАЦИИ модели эти данные хранятся в РСУБД в какой-то табличке, у которой поля называются user_id, message, и time_add — для понимания модели вообще не важно.
3. Если предположить, что другими сущностями, которые ты моделируешь, являются например, Пользователь и Разговор, то становится понятно, что модель Сообщения может иметь метод, который например, вернет модель с предствлением Пользователя, который связан с этим сообщением. Это называется связью один-к-одному.
4. Модель Разговор может содержать в себе информацию обо всех Сообщениях, произошедших в рамках Разговора. Это связь один-к-многим. И например, иметь метод, позволяющий получить набор из последних 10 сообщений. Или отфильтровать их по Пользователю.
-- Типа, реальность
5. Когда в КОНКРЕТНОЙ технической реализации моделей используется реляционная база данных, возникает очевидная проблема: объектные структуры и их связи плохо и сложно представляются через набор линейных таблиц. Поэтому существуют ORM (Объектно-Реляционное Отображение) — попытка технически обойти эти ограничения, и дать возможность выбирать реляционные линейные данные в объектное представление, и сохранять обратно изменения.
6. Один из вариантов ORM называется AR (Active Record), это самая примитивная реализация ORM, в которой проблема решается таким подходом, что каждая Модель описывает одну строку или набор строк в реальной таблице БД, и связи с другими таблицами. Это самый ПРИМИТИВНЫЙ, ТЕХНИЧЕСКИ ПРОСТО РЕАЛИЗУЕМЫЙ и наиболее легко автоматизируемый способ реализации ORM, и оттого — самый распостраненный. Но по этой же причине он хуже всего соотносится с пониманием того, как взаимодействуют модели.
Вурдалак
Продвинутый новичок
@флоппик у тебя представление о модели, как о структуре данных. Тебе важны свойства (ты же под этим подразумевал поля-атрибуты?), в то время как важнее поведение. Не все модели будут иметь свойства вообще, моделью может быть сервис:
https://ru.wikipedia.org/wiki/Овербукинг
Если у бизнеса есть такая стратегия по сверхбронированию, то должна быть модель, которая её описывает. Её никуда не нужно сохранять.
PHP:
final class OverbookingPolicy
{
public function isAllowed(Cargo $cargo, Voyage $voyage)
{
return ($cargo->getSize() + $voyage->getBookedCargoSize()) <= ($voyage->getCapacity() * 1.1);
}
}Если у бизнеса есть такая стратегия по сверхбронированию, то должна быть модель, которая её описывает. Её никуда не нужно сохранять.
«Заполнение», «фильтрование» больше относится к структурам данных. Описываемое больше относится к read model, а не к domain. Что ты будешь делать, если тебе нужно выводить кол-во сообщений у списка пользователей? Добавишь поле «messagesCount» в User?
AllReady
Новичок
Для 1)... во многих примерах прямо в контроллерах фигачат работу с Eloquent классом...
У меня на загруженном проекте на гит получается тоже самое, просто я перенес эти выборки в модель. Так ведь ? А могу просто в контроллере так же через DB получить то, что нужно и отправить вьюхе ?
---
Для 2) есть ORM Eloquent. Она хорошо справится с этой задачей. Посмотри документацию или примеры. с Английским у тебя как?
С Английским не очень, но суть могу понять. Я вот что не пойму, "хранить эти комментарии в базе". потом, ты пишешь: есть ORM Eloquent. Она хорошо справится с этой задачей. Как ORM Eloquent справляется с хранением комментариев в базе ? Или я этого не понимаю, т.к. даже модель не могу понять ?
AllReady
Новичок
"описывающий предмет моделирования" в случае с пользователями сайта, предметом моделирования будет конкретный пользователь или сама таблица пользователей ? Или ни то, ни другое ? И если мне работать нужно как с одним пользователем, так и со всеми (например вывести их) мне достаточно будет одной модели ?
Если предположить, что другими сущностями, которые ты моделируешь, являются например, Пользователь и Разговор, то становится понятно, что модель Сообщения может иметь метод, который например, вернет модель с предствлением Пользователя, который связан с этим сообщением. Это называется связью один-к-одному. то есть у модели определенного одного сообщения есть метод который вернет пользователя. Я так же могу в модели пользователя создать метод, который вернет его 10 сообщений ? То есть наоборот ? (с точки зрения логики это не правильно будет, я бы наоборот в модели создал метод который вернет 10 сообщений, просто передав ид автора, но это я так к примеру)
эх, накину
@AllReady, здесь предмет моделирования - это действия пользователя, события в сети, реакция твоего ПО. Я бы предпочел назвать модель не предметом, а действием.
Любая информация в мире появляется как результат какого-то события, без событий информации не существует.
Моделируется не сам пользователь, а действия, которые он может сделать. Результат действия называется "состояние" объекта. Например, пользователь может зарегистрироваться, удалить аккаунт, поменять имя, поменять телефон, поменять пароль.
Если тебе нужно узнать автора сообщения - на это есть причина, какое-то событие. Например, пользователь запросил у тебя вывод сообщения или нескольких сообщений.
Соответственно, главную модель можно назвать "Вывод сообщений", это бизнес-логика.
Эта модель задумается откуда же ей взять сообщения, и обратиться к модели "Хранение сообщений". Модель, которая реализует хранение и получение сообщений, называют слоем доступа, хранилищем, или просто моделью. Причем, имя принято давать существительным - class Messages.
"Хранение сообщений" вернет сами сообщения в виде объектов. Эти сообщения называются DTO.
Когда "хранение сообщений" и данные сообщения лежат в одном объекте - это Active Record.
Потом "Вывод сообщений" говорит: Контроллер! Вот твой меч! Отдает DTO или ActiveRecord.
Контроллер радуется и отдает сообщения во View, которое выводит данные в нужном формате.
@AllReady, здесь предмет моделирования - это действия пользователя, события в сети, реакция твоего ПО. Я бы предпочел назвать модель не предметом, а действием.
Любая информация в мире появляется как результат какого-то события, без событий информации не существует.
Моделируется не сам пользователь, а действия, которые он может сделать. Результат действия называется "состояние" объекта. Например, пользователь может зарегистрироваться, удалить аккаунт, поменять имя, поменять телефон, поменять пароль.
Если тебе нужно узнать автора сообщения - на это есть причина, какое-то событие. Например, пользователь запросил у тебя вывод сообщения или нескольких сообщений.
Соответственно, главную модель можно назвать "Вывод сообщений", это бизнес-логика.
Эта модель задумается откуда же ей взять сообщения, и обратиться к модели "Хранение сообщений". Модель, которая реализует хранение и получение сообщений, называют слоем доступа, хранилищем, или просто моделью. Причем, имя принято давать существительным - class Messages.
"Хранение сообщений" вернет сами сообщения в виде объектов. Эти сообщения называются DTO.
Когда "хранение сообщений" и данные сообщения лежат в одном объекте - это Active Record.
Потом "Вывод сообщений" говорит: Контроллер! Вот твой меч! Отдает DTO или ActiveRecord.
Контроллер радуется и отдает сообщения во View, которое выводит данные в нужном формате.
Последнее редактирование:
A1x
Новичок
вот кстати в доке Доктрины они используют термин модель в значении Domain model, а не в отношении отдельных классов сущностей (Entity), отображаемых на таблицы.
Вурдалак
Продвинутый новичок
У тебя какое-то неправильное понимание domain model.
@A1x,
не "структура данных представленная одной или несколькими сущностями и связями между ними, плюс поведение", а только поведение, которое называется интерфейсом, части которого могут быть реализованы в форме публичных или магических полей
вообще, тред стоит читать, а не аппендить
не "структура данных представленная одной или несколькими сущностями и связями между ними, плюс поведение", а только поведение, которое называется интерфейсом, части которого могут быть реализованы в форме публичных или магических полей
Последнее редактирование:
Да дайте вы человеку сраные anemic models сделать для начала. А то и правда повесится 
С анемиками он хотя бы сможет понять, о чем там говорится в документации на Eloquent и прочих Doctrine, он же даже это пока не осилил. А рассуждения про DDD для него на текущем уровне вообще как китайская грамота.
С анемиками он хотя бы сможет понять, о чем там говорится в документации на Eloquent и прочих Doctrine, он же даже это пока не осилил. А рассуждения про DDD для него на текущем уровне вообще как китайская грамота.
AllReady
Новичок
До этого момента впитал как губка. А дальше уже надо погуглить.
Что касается Active Record, я так понял, что Active Record это работа с таблицей, через модель ? Точнее доступ к таблицам через модель. Причем в этой модели описываются например все поля таблицы и необходимые нам методы. Допустим мой метод инсерт в самой модели я переделал так:
PHP:
$post = new Post();
$post->title = $title;
$post->subtitle = $subtitle;
$post->user_id = $user_id;
$post->url = Str::slug($title);
$post->save();
PHP:
$post = new Post($title, $subtitle ... );
$post->save();