24 мая прошел первый вводный стрим по архитектуре на www.patreon.com/soersoft Это ежемесячное событие, следующий стрим в июне. Чтобы было понятно какие примерно темы мы обсуждаем на стриме делюсь этим видео...
Спасибо за видео! 1) В вашей реализации "CRUD" вы не достигаете полиморфизма, т.к. другие классы на вход обязаны будут ждать экземпляры класса "User" (естественно учитывая строгую типизацию в TS и disable any). В этом случае достигнуть передачу нового класса можно только за счет наследования от "User", а не полиморфизма. Для "CRUD" нужно было создавать отдельный интерфейс и реализовывать его "User implements ICrud", и в других частях программы уже ждать на вход или создавать "ICrud", например в компоненте. А еще луче сделать generic "ICrud". Поэтому пример с "User" не удачный для показа полиморфизма, только путает новичков. 2) Также согласно wiki вы нарушаете принцип "Инверсии зависимостей", т.к. Деталь - компонент, зависит от детали - "User", а не абстракции. Если Деталь - компонент, будет зависеть от детали - "ICrud" или "IUser", то инверсия зависимостей соблюдется. Kungs - Never Going Home
Здравствуйте! Всё круто, спасибо. Но почему поле user (таймкод 6:00) инициализируется в ngOnInit, а не в constructor? Это же инициализация поля класса, она обычно выполняется в конструкторе. Здесь же не нужны @Input'ы для инициализации поля user. Режим strict в TS, вроде бы, должен на это ругнуться.
Очень интересный Грэсп. Я кстати, думал об этом: чтобы определять работу оборудования через нечто подобное + сразу управлять данными + им же распараллелить работу этого оборудования (т.е. изначально заложить архитектуру, пусть не самую скоростную, главное комфортабельное) . Пока, конечно, это всего лишь идеи, но когда то и кабельный телефон с барашком (циферблатом) тоже был какой то очень странной идеей.
Предложение поменять цветовую схему в Vim'е. Синее на черном (комментарии) не очень разборчивы. И вообще странное использование вима, когда не используются его возможности (удалять по одной букве и т.д.)
В теоретической части про MVC, можно сказать, что используется его "продолжение" MVP (Presenter), а не традиционный MVC? Старый-добрый MVC подразумевает использование в более простых системах, где Model напрямую обновляет View, а Controller лишь осуществляет реакцию на действия пользователя (т.е фактически это скорее двумодульная архитектура, где кроме модели выделен модуль обработки действий пользователя). И в этой системе пользователь и правда напрямую обращается к контроллеру, но контроллер может быть вообще не связан с View (как клавиатура и экран монитора). Model View Presenter же как раз подразумевает прослойку Presenter между Model и View. Он не только выполняет обработку действий пользователя, вызывая реакции в модели, но и определяет, как из модели данные будут переданы в View. Т.е Presenter является контроллером в обе стороны и является чистым посредником GRASP. Логически смысл Presenter-а получается в адаптации тяжеловесной модели к конкретному отображению. Наверное, это излишний пуризм и в сообществе под MVC часто имеется в виду MVP. Но, думаю, в контексте GRASP полезно понимать, что Controller отвечает за обработку действий в одну сторону, что и отделяет его от посредника. А то в некоторых печальных приложениях из него ошибочно делают god-object. По поводу MVC vs MVP есть часть в отличной лекции Роберта Мартина: ruclips.net/video/o_TH-Y78tt4/видео.html
@@S0ERDEVS согласен, что современный MVC (Web MVC) это что-то совсем иное. Но интересная у этого паттерна история выходит. В некоторых статьях и книгах используют старый вариант (как у Дяди Боба), в некоторых современный. Интересно было бы послушать разбор этого злосчастного MVC на примере разных фреймворков: чем современный отличается от MVP, за что же в итоге отвечает контроллер, какие на нем ограничения, где всё-таки располагается бизнес-логика и прочие разночтения. Другими словами, ряд видео об архитектуре очень полезны.
Не совсем понятно разделение UserModel и User. Все методы по переименованию и т.п можно было прямо в User и вставлять. К тому же этот постфикс "Model" слишком мне кажется, ибо класс и так подразуемвает под собой модель. Второй момент, как я понял, вы хотите вынести UserModel в сервис и инжектить его. Но для чего? В этом мог бы быть смысл, если бы что-то тоже инжектилось в модели. Но как мне кажется, инжектить в модели в корне неправильно. Клиентские "доменные" модели не должны инжектиться с помощью DI. Их должен создавать информационный эксперт, да даже в компоненте её создать будет вполне нормально
Непонятна целевая аудитория канала. Для опытных программистов ничего нового, а для новичка сильно сложная информация. По моему это раскрутка для контор которые проводят курсы.
ты сразу на английский переводи. а то какие то зацепления, связности... ничего не понятно. нормальные программеры эти термины только на ангельском знают.
Увы, понятнее не стало, ты остановился на полпути. И раз уж ты остановился на идее рефакторинга модели в сервис, то по сути ты пересказываешь официальную документацию Ангуляр, где все это есть. Неужели есть люди, которые донатят за пересказ оф доки?
Зачем вопросы не относящиеся к теме обсуждения? Тебе есть разница в терминале или редакторе? Видимо, ты слишком много внимания уделяешь "шашечкам", по крайней мере тему видео ты явно не понял, но почему-то разобраться не хочешь.
В модели не должно быть такого. Это же модель которая должна отражать реальные бизнес процессы. А вот юзкейз по созданию модели, с названием create, уже может быть.
24 мая прошел первый вводный стрим по архитектуре на www.patreon.com/soersoft
Это ежемесячное событие, следующий стрим в июне. Чтобы было понятно какие примерно темы мы обсуждаем на стриме делюсь этим видео...
Это видео не только про MVVM, но и про выход с Vim, Спасибо S0ER помог!
Хочу продолжение)
Все хотят! Терпи :p
Спасибо за видео!
1) В вашей реализации "CRUD" вы не достигаете полиморфизма, т.к. другие классы на вход обязаны будут ждать экземпляры класса "User" (естественно учитывая строгую типизацию в TS и disable any). В этом случае достигнуть передачу нового класса можно только за счет наследования от "User", а не полиморфизма. Для "CRUD" нужно было создавать отдельный интерфейс и реализовывать его "User implements ICrud", и в других частях программы уже ждать на вход или создавать "ICrud", например в компоненте. А еще луче сделать generic "ICrud". Поэтому пример с "User" не удачный для показа полиморфизма, только путает новичков.
2) Также согласно wiki вы нарушаете принцип "Инверсии зависимостей", т.к. Деталь - компонент, зависит от детали - "User", а не абстракции. Если Деталь - компонент, будет зависеть от детали - "ICrud" или "IUser", то инверсия зависимостей соблюдется.
Kungs - Never Going Home
Что посоветуете в данной теме прочитать/посмотреть?
Классный формат! Такого материала мало и хотелось бы побольше этого формата. Вот еще алгоритмы на code wars зашли хорошо. Круто, что сказать)
Здравствуйте! Всё круто, спасибо. Но почему поле user (таймкод 6:00) инициализируется в ngOnInit, а не в constructor? Это же инициализация поля класса, она обычно выполняется в конструкторе. Здесь же не нужны @Input'ы для инициализации поля user. Режим strict в TS, вроде бы, должен на это ругнуться.
Ждем видео по архитектуре ангуляра!
Очень интересна тема архитектуры Angular 2+!
Очень интересный Грэсп. Я кстати, думал об этом: чтобы определять работу оборудования через нечто подобное + сразу управлять данными + им же распараллелить работу этого оборудования (т.е. изначально заложить архитектуру, пусть не самую скоростную, главное комфортабельное) . Пока, конечно, это всего лишь идеи, но когда то и кабельный телефон с барашком (циферблатом) тоже был какой то очень странной идеей.
Обезательно сними видео о архитектуре angular2! Кому интересно ставьте лаик!
+ за видео об архитектуре ангуляра
извините, но я не могу понять для кого видео??? для реальных программистов или для теоретиков.
Предложение поменять цветовую схему в Vim'е. Синее на черном (комментарии) не очень разборчивы. И вообще странное использование вима, когда не используются его возможности (удалять по одной букве и т.д.)
НЭО-СОЕР ;) Спасибо за видео об архитектуре! Расскажите, пожалуйста, чем рисуете (на что пишите, какой фильтр, ...). Очень интересный эффект
Нашел ответ на свой вопрос: это просто маркерная доска, веб камера, фильтрация и инвертирование цветов.
Судя по форме очков, все-таки Морфиус. Душки чтоб никто не догадался
Интересно, хочу продолжение :)
Жду продолжения )
ангуляр топ
Интересно!
Может оффтоп, подскажи, чем рисуешь?
Маркером на доске, это все снято на видео, уменьшена не прозрачность и добавлен какой-то фильтр скорее всего
Почему не VS Code?
Привет Soer, ждём продолжение по архитектуре Angular))
В теоретической части про MVC, можно сказать, что используется его "продолжение" MVP (Presenter), а не традиционный MVC?
Старый-добрый MVC подразумевает использование в более простых системах, где Model напрямую обновляет View, а Controller лишь осуществляет реакцию на действия пользователя (т.е фактически это скорее двумодульная архитектура, где кроме модели выделен модуль обработки действий пользователя). И в этой системе пользователь и правда напрямую обращается к контроллеру, но контроллер может быть вообще не связан с View (как клавиатура и экран монитора).
Model View Presenter же как раз подразумевает прослойку Presenter между Model и View. Он не только выполняет обработку действий пользователя, вызывая реакции в модели, но и определяет, как из модели данные будут переданы в View. Т.е Presenter является контроллером в обе стороны и является чистым посредником GRASP. Логически смысл Presenter-а получается в адаптации тяжеловесной модели к конкретному отображению.
Наверное, это излишний пуризм и в сообществе под MVC часто имеется в виду MVP. Но, думаю, в контексте GRASP полезно понимать, что Controller отвечает за обработку действий в одну сторону, что и отделяет его от посредника. А то в некоторых печальных приложениях из него ошибочно делают god-object.
По поводу MVC vs MVP есть часть в отличной лекции Роберта Мартина: ruclips.net/video/o_TH-Y78tt4/видео.html
Вы привели MVC в интерпретации 80-х годов прошлого века, к сожалению идея MVC была очень сильно искажена в последующие годы, особенно в рамках веба.
@@S0ERDEVS согласен, что современный MVC (Web MVC) это что-то совсем иное. Но интересная у этого паттерна история выходит. В некоторых статьях и книгах используют старый вариант (как у Дяди Боба), в некоторых современный. Интересно было бы послушать разбор этого злосчастного MVC на примере разных фреймворков: чем современный отличается от MVP, за что же в итоге отвечает контроллер, какие на нем ограничения, где всё-таки располагается бизнес-логика и прочие разночтения. Другими словами, ряд видео об архитектуре очень полезны.
Давай продолжение!)
Идея с графическим планшетом шикарна, только цвета не хватает.
Да! GRASP - из вэри интерестинг!
Огонь
Почему комментарии темносиние на черном фоне :)
Ставлю лайк за то, что похож на Базилио!!)
Зловещий сибирский Базилио)
Морфеус))) лайк
+ за архитектуру ангуляра
Продолжение!
Не совсем понятно разделение UserModel и User. Все методы по переименованию и т.п можно было прямо в User и вставлять. К тому же этот постфикс "Model" слишком мне кажется, ибо класс и так подразуемвает под собой модель.
Второй момент, как я понял, вы хотите вынести UserModel в сервис и инжектить его. Но для чего? В этом мог бы быть смысл, если бы что-то тоже инжектилось в модели. Но как мне кажется, инжектить в модели в корне неправильно. Клиентские "доменные" модели не должны инжектиться с помощью DI. Их должен создавать информационный эксперт, да даже в компоненте её создать будет вполне нормально
это сделано что бы показать идею саму grasp, понятно так не пишет не кто, тем более современные приложения
да
IT-шники -душнилы, все про архитектуру в комментах пишут, и даже никто не обратил внимание на крутые очки)
Непонятна целевая аудитория канала. Для опытных программистов ничего нового, а для новичка сильно сложная информация. По моему это раскрутка для контор которые проводят курсы.
ты сразу на английский переводи. а то какие то зацепления, связности... ничего не понятно. нормальные программеры эти термины только на ангельском знают.
Увы, понятнее не стало, ты остановился на полпути. И раз уж ты остановился на идее рефакторинга модели в сервис, то по сути ты пересказываешь официальную документацию Ангуляр, где все это есть. Неужели есть люди, которые донатят за пересказ оф доки?
Где в документации написано про GRASP? Я не видел, можешь ссылкой поделиться?
@max kolganoff там скорее всего хромакей и черно белый инвертированный эффект
@max kolganoff это просто маркерная доска, веб камера, фильтрация и инвертирование цветов.
Я первый
А использовать нормальный редактор и dev сервер ангуляра было сложно? Зачем эти понты с программированием в терминале?
Зачем вопросы не относящиеся к теме обсуждения? Тебе есть разница в терминале или редакторе? Видимо, ты слишком много внимания уделяешь "шашечкам", по крайней мере тему видео ты явно не понял, но почему-то разобраться не хочешь.
@@S0ERDEVS не слушай его контент топ
Фуфу 4 символьный отступ вместо 2х... :D
Соер. в очках не то.
Зато глаза не болят от света.
Подрался наверное с каким нибудь Шарпистом который сказал что Жаба отстой...
В модели не должно быть такого. Это же модель которая должна отражать реальные бизнес процессы. А вот юзкейз по созданию модели, с названием create, уже может быть.