Это конечно замечательно, что вы столько выдержек из теории выдали (спасибо, правда), НО из этих выдержек абсолютно не следует, что представление модели изложенное в статьи противоречит этим определениям.
Мораль: не читайте то, что написано на заборе, читайте первоисточники.
Да, каюсь, некорректно привел информацию о модели в парадигме MVC, но речь в статье НЕ заключалась в объяснении MVC, а рассмотрение конкретного примера работы с моделями.
Из ложной посылки можно сделать любые выводы, но какая в них ценность?
А в чем тут ложность? Вы сами приводите сноску о том, что модель — это объект предоставляющий информацию о домене. По вашему домен != бизнес-логика?
Создается ощущение, что вы решили, что (в Domain Model) модель и сущность — это одно и то же. Так вот, нет:
А что в вашей сноске подтверждает ваше утверждение? Модель и сущность — это термины означающие одно и то же: объект предметной области обладающей поведением и данными данной предметной области. Если вы имеете ввиду различные вспомогательные ValueObject и определяете их как сущности — это опять вопрос терминологии. Даже если мы возьмем такой пример VO как «деньги», то это тоже модель, но без поведения как такового.
Объектная модель домена. То есть, внезапно, слово «модель» относится к целому, а не к его частям. Вот подтверждающая цитата, где модель и составляющие ее объекты противопоставляются:
Вообще не подтверждающая цитата. Здесь лишь говорить о том что модели могут раздуваться до огромных размеров, но это уже вопросы проектирования и реализации, а не подхода как такового. В статье идет разделение на «целое и часть» в рамках конкретной сущности бизнес-логики (например «пост — комментарий»).
То есть допустим, если у нас есть объект «Департамент», который действительно может быть большим, НО большой объект != сложный объект. Если декомпозировать эту модель на его «части» и логику реализовать с помощью бизнес-операций (пример реализации в статье), то объект будет просто большим, но ничуть не сложным.
У вас у «модели» Post куча сеттеров и геттеров, где тут бизнес логика?
Об этом было ближе к концу в разделе бизнес-операции. Ну либо если это не является бизнес-логикой, то даже не знаю какой должна быть БЛ у блога.
интерфейс репозитория зависит от КЛАССА, абстракция зависящая от реализации, окей.
В данной ситуации, когда 1 интерфейс = 1 реализация, а вторая не планируется не ранее чем никогда, делать очередной интерфейс — излишество.
далее там даже коментить не охото где di это singleton который юзается в других singleton и тд
Ну собственно, а как вы хотите внедрять зависимости?) Прокидывать контейнер через все классы до конечного использования? В методе createInstance идея в том, чтобы спрятать сам контейнер и просто создавать экземпляры с уже нужными инъекциями.
Очень зря) Я не говорю что базой вообще не стоит заниматься, я говорю что строить сущности на основе таблиц в корне неправильно с точки зрения последующей реализации бизнес-логики будут проблемы (в статье это есть).
Нет, не так. Олимпиадников и победителей грантов учим БЕСПЛАТНО. Для остальных — сильно дорого, но возможно.
Ну то есть очередной условие «сильно дорого». Типа способные дарования должны по определению иметь пачку купюр (или их родители). Отличная логика! Старый добрый конкурс 100500 человек на 1 место видимо уже не катит.
И? Не хотят — идут лесом. Хотят? Добро пожаловать. О чем я и говорил. Единственное препятствие на пути в Иннополис — мозги. Если их нет, то дорога, увы, закрыта.
Что за детский сад? Не могут — идут лесом. Но, например, жилье часто оплачивают работодатели. Помощь с переездом также есть.
Это конечно забавно вы из контекста слова вырвали, полностью фраза была «не хотят или не могу приехать». Не хотят потому что интроверты например. То есть во времена удаленки давайте собирать всех с релокацией в одном месте. Оукей!
Видимо просто бывают люди, которые будут ныть всегда. Что хорошего ни сделай.
Конечно! Вот только в данной ситуации не про это речь, а про то что идея может быть и хорошая, но есть варианты как сделать лучше (ну по крайней мере по моему скромному не искушенному и естественно субъективному и крайней непрофессиональному мнению).
Но видимо резиденты и амбассадоры Иннополиса со слишком ранимой душой и любое критическое мнение воспринимают слишком близко к сердцу.
В основном студенты университета – это победители и призеры всероссийских олимпиад
Ну то есть мы берем только олимпиадников и учим их. И по факту со всей России все стекаются в Татарстан (что как бы не совсем Россия с наличием своей конституции, ну да ладно). И плюсом те кто не хотят или не могут приехать в Иннополис — идут лесом.
Этот пример получше выглядит, чем выглядел бы с использованием наследования или слотов.
Дак а там и вообще не про наследование))) Ну, а по поводу лучше/хуже — визуально разница только в местонахождении логики, никаких профитов не вижу (по факту это группировка by features и не by types, тоже самое что и с файлами).
Есть наследование компонентов и слоты для таких ситуаций. Ну и в целом никто не мешает кусок функционала вынести в класс-helper и обращаться из компонента уже к нему.
Ну и раз уж зашел разговор, а как composition API, то спасет от этого?
Думаю, что запаритесь выносить. Состояние и методы жизненного цикла вряд ли получится легко вынести. К тому же каждый будет это по разному делать, что плохо.
Немного не про это речь. Все что относиться к компоненту, должно находиться в компоненте. Выносить нужно то, что относиться к бизнел-логике, либо работе с данными (ту же самую обработку данных после получения из store, лучше сразу вынести в отдельный геттер (если это используется еще где-то, или если обработка занимает значительный кусок кода, если нет то computed), также выносить вспомогательные функции в сервисы/хелперы, которые занимаются общими вещами (тот же самый Display из статьи, или допустим формирование дерева меню лучше вынести из компонента (даже несмотря на то что используется это только в единственном компоненте). Вообщем в идеале в компоненте должна остаться только логика компонента, обращение к store и хелперам
1. Сколько не пишу, а группировка файлов by features в разы удобнее, чем по типам сущности (стор, компонент, api).
Для меня если честно загадка почему) Поиск файлов плюс/минус один и тот же, структурно выглядят плюс/минус также.
3. Когда сторов несколько (у вас не та ситуация), не вижу особой надобности создавать еще и модели. Максимум описание типа объекта задавать, чтобы использовать правильный тип при передачи в функции.
В данном проекте модели излишки с точки зрения бизнес-логики, но для типизирования я думаю их в любом случае лучше заводить (каких бы размеров не был проект), тогда компоненты становятся более «понятными».
4. Передача и вызов Api в сторе?… я такой предпочитаю:
вызвать api метод, api метод вызывает метод обновления стора.
А не превращается это в кашу? Ну то есть компоненты могут обращаться и к store (как минимум для чтения) и к API, а по факту действий ровно столько же, только инициирует их API, а не store. Мне кажется лучше компоненты отделять от API, ну по крайней мере не могу представить кейс когда обращение только к store усложнит приложение.
5. blog.js у вас на верном пути к god object. Увеличьте количество полей в его state до нескольких десятков и представьте, насколько он увеличится, если ко всему этому написать геттеры, мутации, сеттеры.
Да, согласен, лучше раскидать по файлам: getters, mutations, actions, store
Видимо я очень сильно промахнулся с названием, либо вы просто дальше заголовка не читали) В статье описана оптимальная структура SPA (на примере блога), также описан пример работы с роутером и с vuex, как именно должны они взаимодействовать с компонентами. И все эти рекомендации можно смело применять и к большому приватному корп порталу (не нуждающего в великом и ужасном SEO) и к мать его простенькому блогу на примере которого были рассмотрены эти рекомендации!
P.S. «знатоки» и в задачке «2+2» могут говна наплодить ;-)
Эээ, почему ее нельзя применить? Да скорее всего промахнулся с названием статьи, ведь суть статьи не в создании блога, а в создании ПРАВИЛЬНОЙ структуры SPA на примере блога.
Немного не про это статья) Тут суть была в том, чтобы показать как структурно должно все выглядеть, а чтобы описать все «тонкости» SEO это нужно как минимум парочку статей, да и не полностью это от фронта зависит.
Дак а смысл? Изменился синтаксис и теперь группировать код в компоненте можно по смыслу, а не типам как в Options API (data, computed, watch, ...). Если изначально компоненты не нагружать лишними обязанностями, а выносить все в сервисы и модели, то и сами компоненты будут не «тяжелыми» и бизнес-логика и сервисы могут быть переиспользованы. Вообщем Composition API на первый взгляд попытка Vue бороться с говнокодерами и быть похожемы на React и не более. Но возможно я не прав)
Ну вот когда доберетесь до продакшена и деплоев посерьезнее, тогда может быть разберетесь в тонкостях.
Вам лень поделиться? Или вы не знаете?
судя по приведенному листенингу вы не определились.
Эээ и в чем же неопределенность? Для каждого образа есть своя директория в нужными параметрами, в каждом примере структура сохраняется.
типичная путаница в терминах, не «контейнеры» а «образы». Лучше бы потратили один-два абзаца что бы хотя бы самому для себя разобрать в чем разница.
Это не путаница, я не посчитал нужным вводить очередной термин, т.к. когда начинаешь читать про докер, на тебя сразу вываливается контейнеры, volume, образы, слои и др. Не вижу смысла забивать статью терминологией, если по контексту это не особо важно и критично.
Повторюсь, что статья в большей степени для начинающих, чтобы не особо вдаваясь в термины docker научиться с ним работать (с docker-compose). Чтобы узнать что такое докер в конце статьи ссылки приложены.
nginx отправляет запрос на php-fpm, а по вашей диаграмме они типа независимо обрабатывают запросы.
Это блок-схема, а не диаграмма активности или коммуникации.
а потом толпы лемингов атакуют чаты с глупыми вопросами, которые устраняются вечером чтения документации/чтения статей.
А следующий абзац лень прочитать? «Да, конечно, для тонкой настройки или сложных задач, необходимо уже углубляться в дебри docker, но в средне-статистическом случае — это не нужно.»
Программа должна работать без «volumes» в docker-compose (Их можно опционально добавлять при девепоменте, чтобы изменения в файлах хоста автоматически переносились в запущенный контейнер и не надо было билдить и запускать новый image каждый раз когда надо увидеть внесенные в код изменнения)
Но тогда получатся разные конфиги для prod и для dev, по моему это вообще не огонь, или альтернативного решения нет?
Конфиги и все файлы из src должны «запекаться» в image при помощи ADD/COPY инструкций Dockerfile.
А почему нельзя так оставить, обязательно в образ пихать?
По факту тоже самое получается, или в чем тонкость?
Docker отслеживает изменения docker-compose.yml или только изменения Dockerfile?
Да, каюсь, некорректно привел информацию о модели в парадигме MVC, но речь в статье НЕ заключалась в объяснении MVC, а рассмотрение конкретного примера работы с моделями.
А в чем тут ложность? Вы сами приводите сноску о том, что модель — это объект предоставляющий информацию о домене. По вашему домен != бизнес-логика?
А что в вашей сноске подтверждает ваше утверждение? Модель и сущность — это термины означающие одно и то же: объект предметной области обладающей поведением и данными данной предметной области. Если вы имеете ввиду различные вспомогательные ValueObject и определяете их как сущности — это опять вопрос терминологии. Даже если мы возьмем такой пример VO как «деньги», то это тоже модель, но без поведения как такового.
Вообще не подтверждающая цитата. Здесь лишь говорить о том что модели могут раздуваться до огромных размеров, но это уже вопросы проектирования и реализации, а не подхода как такового. В статье идет разделение на «целое и часть» в рамках конкретной сущности бизнес-логики (например «пост — комментарий»).
То есть допустим, если у нас есть объект «Департамент», который действительно может быть большим, НО большой объект != сложный объект. Если декомпозировать эту модель на его «части» и логику реализовать с помощью бизнес-операций (пример реализации в статье), то объект будет просто большим, но ничуть не сложным.
Об этом было ближе к концу в разделе бизнес-операции. Ну либо если это не является бизнес-логикой, то даже не знаю какой должна быть БЛ у блога.
В данной ситуации, когда 1 интерфейс = 1 реализация, а вторая не планируется не ранее чем никогда, делать очередной интерфейс — излишество.
Ну собственно, а как вы хотите внедрять зависимости?) Прокидывать контейнер через все классы до конечного использования? В методе createInstance идея в том, чтобы спрятать сам контейнер и просто создавать экземпляры с уже нужными инъекциями.
Просто шикарная подача информации! На каком слайде нужно остановится про модели?)
А источники да, добавил.
Ну то есть очередной условие «сильно дорого». Типа способные дарования должны по определению иметь пачку купюр (или их родители). Отличная логика! Старый добрый конкурс 100500 человек на 1 место видимо уже не катит.
Это конечно забавно вы из контекста слова вырвали, полностью фраза была «не хотят или не могу приехать». Не хотят потому что интроверты например. То есть во времена удаленки давайте собирать всех с релокацией в одном месте. Оукей!
Конечно! Вот только в данной ситуации не про это речь, а про то что идея может быть и хорошая, но есть варианты как сделать лучше (ну по крайней мере по моему скромному не искушенному и естественно субъективному и крайней непрофессиональному мнению).
Но видимо резиденты и амбассадоры Иннополиса со слишком ранимой душой и любое критическое мнение воспринимают слишком близко к сердцу.
Ну то есть мы берем только олимпиадников и учим их. И по факту со всей России все стекаются в Татарстан (что как бы не совсем Россия с наличием своей конституции, ну да ладно). И плюсом те кто не хотят или не могут приехать в Иннополис — идут лесом.
Дак а там и вообще не про наследование))) Ну, а по поводу лучше/хуже — визуально разница только в местонахождении логики, никаких профитов не вижу (по факту это группировка by features и не by types, тоже самое что и с файлами).
Ну и раз уж зашел разговор, а как composition API, то спасет от этого?
Немного не про это речь. Все что относиться к компоненту, должно находиться в компоненте. Выносить нужно то, что относиться к бизнел-логике, либо работе с данными (ту же самую обработку данных после получения из store, лучше сразу вынести в отдельный геттер (если это используется еще где-то, или если обработка занимает значительный кусок кода, если нет то computed), также выносить вспомогательные функции в сервисы/хелперы, которые занимаются общими вещами (тот же самый Display из статьи, или допустим формирование дерева меню лучше вынести из компонента (даже несмотря на то что используется это только в единственном компоненте). Вообщем в идеале в компоненте должна остаться только логика компонента, обращение к store и хелперам
Для меня если честно загадка почему) Поиск файлов плюс/минус один и тот же, структурно выглядят плюс/минус также.
В данном проекте модели излишки с точки зрения бизнес-логики, но для типизирования я думаю их в любом случае лучше заводить (каких бы размеров не был проект), тогда компоненты становятся более «понятными».
А не превращается это в кашу? Ну то есть компоненты могут обращаться и к store (как минимум для чтения) и к API, а по факту действий ровно столько же, только инициирует их API, а не store. Мне кажется лучше компоненты отделять от API, ну по крайней мере не могу представить кейс когда обращение только к store усложнит приложение.
Да, согласен, лучше раскидать по файлам: getters, mutations, actions, store
P.S. «знатоки» и в задачке «2+2» могут говна наплодить ;-)
Вам лень поделиться? Или вы не знаете?
Эээ и в чем же неопределенность? Для каждого образа есть своя директория в нужными параметрами, в каждом примере структура сохраняется.
Это не путаница, я не посчитал нужным вводить очередной термин, т.к. когда начинаешь читать про докер, на тебя сразу вываливается контейнеры, volume, образы, слои и др. Не вижу смысла забивать статью терминологией, если по контексту это не особо важно и критично.
Повторюсь, что статья в большей степени для начинающих, чтобы не особо вдаваясь в термины docker научиться с ним работать (с docker-compose). Чтобы узнать что такое докер в конце статьи ссылки приложены.
Это блок-схема, а не диаграмма активности или коммуникации.
А следующий абзац лень прочитать? «Да, конечно, для тонкой настройки или сложных задач, необходимо уже углубляться в дебри docker, но в средне-статистическом случае — это не нужно.»
Но тогда получатся разные конфиги для prod и для dev, по моему это вообще не огонь, или альтернативного решения нет?
А почему нельзя так оставить, обязательно в образ пихать?
По факту тоже самое получается, или в чем тонкость?
Docker отслеживает изменения docker-compose.yml или только изменения Dockerfile?