Да ручками прикручивать лень, а по зависимостям если притащить стандартные бандлы на твиг, хранимые сессии и тд - практически в полновесный laravel уже и превратится.Серверный рендеринг - не самая большая проблема, как по мне, и большой фреймворк для этого не нужен, максимум - смарти-твиг.
analogue - это такой датамаппер на основе eloquent, в репозиториях для find/persist/delete sql и не нужен (достаточно генерируемого), это, конечно, намного тяжелее, чем простой QB, но писать ручками маппинг-персистенцию очень лень и не вижу смысла. А аналитику и подобное (что не ложится на entities) пишу отдельными классами через квери билдер или raw sql - там уже на выходе не сущности, а специфичные для этой аналитики объекты и их коллекции.А с микрофреймворками вы sql выносите в отдельный слой, или прямо в сущностях/коллекциях/моделях пишите?
Звучит как разделение на write и read models. Им бы чо попроще, ведь по их логике одна модель проще двух, зачем множить сущности Ж)analogue - это такой датамаппер на основе eloquent, в репозиториях для find/persist/delete sql и не нужен (достаточно генерируемого), это, конечно, намного тяжелее, чем простой QB, но писать ручками маппинг-персистенцию очень лень и не вижу смысла. А аналитику и подобное (что не ложится на entities) пишу отдельными классами через квери билдер или raw sql - там уже на выходе не сущности, а специфичные для этой аналитики объекты и их коллекции.
Граница между entities и «вообще не entities» на самом деле размыта. Если ты выводишь список пользователей, а потом понадобилось выводить ещё кол-во заказов рядом с каждым, то что ты будешь делать: вводить в сущность денормализованное поле с кол-вом заказов или будешь подсчитывать кол-во в каждой итерации?Не, я не разделяю (в том случае, о котором говорю). Речь об аналитике-статистике и подобных вещах, где на выходе вообще не entities.
если не сущности, то что они возвращают - value object в виде 3-мерного массива?аналитику и подобное (что не ложится на entities) пишу отдельными классами через квери билдер или raw sql - там уже на выходе не сущности, а специфичные для этой аналитики объекты и их коллекции.
Массивы неудобны тем, что состав полей неявный, никак не гарантируется и нет автокомплита. Обычно делается какой-то VO а-ля DailyUserReport (DailyUserDto, DailyUserReadModel, etc.) или что-то такое для твоего конкретного use case, который будет содержать необходимый набор read-only полей.если не сущности, то что они возвращают - value object в виде 3-мерного массива?
final class UserDto
{
private $id;
private $name;
private $ordersQuantity;
public function __construct($id, $name, $ordersQuantity)
{
// ...
}
// ...
}
Зачем? Отдельным классом читалка, и там, условно говоря, PDO::FETCH_CLASS = UserDtoто есть класс, который генерирует этот VO - обертка для статических функций с sql?
UserDto генерируется сервисом:не то чтобы "зачем", в "читалке" с sql классе не будет состояния, f данные выносятся в VO, то есть анемичная модель?
final class MySqlUserQueryService implements UserQueryService
{
public function __construct(PDO $pdo)
{
// ...
}
public function find($id)
{
// ...
return new UserDto(...);
}
// ...
}
я правильно понимаю, что у вас получается анемичная модель?these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects
Read model не является domain model, поэтому некорректно говорить, что это anemic domain model. Там и не должно быть бизнес-логики.да, я о том же
правильно понимаю, что у вас по сути анемичная модель?
В ArrayObject, который оформлен в виде класса, нет методов для запросов. Класс, который его отдает - тоже не read model.A read model is a model specialized for reads, that is, queries. It takes events produced by the domain and uses them to build and maintain a model that is suitable for answering the client's queries.
https://en.wikipedia.org/wiki/Value_objectА value object is a small object that represents a simple entity. Examples of value objects are objects representing an amount of money or a date range.
проблемы в том, что:Судя по коду роут класса - это не бага, а фича
точно такое же поведение во всех реализациях PSR-7 (что ze, что slim, что radar)
Т.е. работу с выводом реализовать только через методы response. А если нужен прямой вывод через echo или print то использовать 'outputBuffering' append или prepend но не false
то есть, то, о чём мы говорим, похоже на anemic model, read model, DTO, и VO.То, о чём мы говорим, одновременно является и read model, и DTO, и VO. Просто эти понятия из разных плоскостей.
iPhone является мобильником; с другой точки зрения он, вероятно, является смартфоном; а с ещё одной точки зрения он является железкой. Эти понятия друг друга взаимно не исключают.
Да, это выглядит примерно так: мы говорим про read models, и тут приходишь ты и заявляешь, что вообще-то то, о чём мы говорим, походит на объект и приводишь определение объекта из ООП.то есть, то, о чём мы говорим, похоже на anemic model, read model, DTO, и VO