npm-пакет с интерфейсами не в минус… На мой взгляд, прям вот чтобы независимые команды независимо мимо спринтов пилили микросервисы — это далеко от практики.
Но вот практический пример: в реквесте один параметр из опционального решили сделать обязательным, обновили базовый образ, автоматом обновили везде package.json, — и вдруг перестал собираться всеми забытый микросервис. Это же прекрасно, что ошибка обнаружилась на этапе компиляции, а не на проде где-то что-то отвалилось и надо искать где и что. Это вот прям жирнейший плюс общего пакета
В «разведении БД» есть психологический момент, что нужно свыкнуться с мыслью, что данные дублируются. Не все данные, но всё же — прям очень некомфортно с этой мыслью. Но можно использовать психологический трюк — рассматривать это дублирование данных как своего рода кэш. И тогда можно спокойно спать по ночам
Нет, конечно. Если БД нужна, она у каждого своя. Общих БД у микросервисов нет. Но они общаются между собой — синхронизованные сообщения через GET/POST, асинхронные через nats-streaming эвенты. Сигнатура запросов и эвентов, а также доменные модели, какие-то общие утилиты и т.д. в общем пакете. Удобно, когда и бэкэнд и клиент у тебя на Typescript. Могут использовать общий код
+ централизованный апдейт пакетов сокращает время апдейта в столько раз, сколько микросервисов имеется, это имеет прямое отношение к экономической целесообразности. Даже не прямое, а геометрическое :)
Прям вот ограничений особых и нет, а вот польза от уменьшения приличная.
Отмечу, кстати, что это уменьшение скорее не на 3Гб, — а скорее уменьшение в 20+ раз. Это сильно сказывается, когда приходится обновлять установ на продакшене или тестовом контуре. Одно дело, когда удаленный сервак выкачивает 3 Гб, и совсем другое, когда 0.15 Гб. Да даже не удаленный сервак, а локальное хранилище образов гораздо лучше себя чувствует.
А целиком все микросервисы обновляются периодически. У нас есть npm-пакет с интерфейсами и т.д. общий для всех микросервисов, он обновляется нередко. И каждый раз пушить 3 Гб, а потом тянуть их — так себе
1) А теперь представьте, что MsA разрабатывает одна команда, а MsB другая?
Ээ… Разрабатывают разные команды… и?
2) А ещё у вас 20 сервисов. Вы обновили в одном пакет и сломали другие 19. Придется вам не обновляться…
На практике вообще не проблема. На практике есть небольшой набор общих для всех микросервисов пакетов, (а конкретно mongoose, axios, nats, express, ..) и некоторым микросервисам нужны специфичные пакеты, которые больше никто не использует.
Например один микросервис отвечает за рендеринг PDF, другой за вебсокеты, третий за связь со сторонним приложением.
Добавить специфичный пакет в базовый образ — не страшно, это никак не отразится на других 19. Обновить свой специфичный пакет (например рендеринга PDF) — опять же, не страшно. Другие 19 он никак не заденет.
Другое дело если пакет общий. Например, если вышла новая мажорная версия mongoose с брейкин ченджем. Тогда либо надо собрать силу волю и команды в кулак — и всем вместе обновится. Либо, если вам так нужна новая фича в монгусе, а других подбить на апдейт не получается — то просто базируете свой микросервис не на общем BaseMS, а на Node по старинке. (но на практике такого не помню)
3) Также если у вас 20 сервисов, шанс что пакеты устаканится стремится к нулю
Повторюсь — добавлять и обновлять специфичные пакеты в базовый образ — не страшно.
Спасибо, конечно, но по ссылке говорят: «Используйте alpine!», а в статье как раз он
Кроме того, в статье кардинальный способ уменьшения вклада каждого микросервиса в общий размер. Только на размер пожатого вебпаком исходника. С трудом представляю, как порезать еще хоть чуть-чуть.
Это не enterprise код, мы тут фокусируемся не на том, как подписываться, — от этого я абстрагируюсь. Фокус на MVVM.
Что касается ObservableCollection, так смысл как раз в том, чтобы она не руками обновлялась Refresh()'ем, а автоматически. Вьшка вся не перестроится — это не веб:) — автоматически произойдет частичное обновление вью, как и задумывалось.
В конкретной программе есть коллекция с динамическим размером — это список покупок пользователя.
Я использую Prism. Вам советую прочитать Adam Nathan: WPF Unleashed, потом посмотреть видеокурсы Брайана Лагунаса про Prism, а потом, собственно, на него и перейти
Нет, направление вашей мысли верное, только это несколько затеняет предмет статьи — MVVM. Такую функцию (Watch) я конечно бы не потащил в enterprise, но в статье я всячески убираю посторонние детали, чтобы сосредоточиться на основных существенных моментах MVVM
Нужды VM формируют интерфейс модели вкупе с основной бизнес задачей (продажей товаров покупателям).
Когда я разрабатываю сначала вьюшку, потом к ней создаю VM, а потом, основываясь на вызовах модели из VM, я создаю саму модель — этот подход View-first. Но есть и другой подход (Model-first) — когда сначала без всякого интерфейса создается модель, потом рисуется интерфейс и только потом вьюшки и модель связываются как клеем VM.
Видимость конкретного элемента управления — вопрос исключительно для View. Он может решаться с помощью привязки к свойству ViewModel, но само это свойство всегда выражается в терминах поведения и состояния приложения, а не View, которое может быть абсолютно любым
Вот вроде говорим об одном… но выводы делаем различные.
Вот допустим у нас в представленной задаче кнопочки с покупками определенных товаров были бы видимы только тогда, когда кредита хватало бы на их покупку.
Модели все равно — видны кнопочки или не видны — даже если вы нажмете на такую кнопку: если денег в кредите недостаточно — модель все равно не продаст вам товар. Теперь, если мы (чисто из визуальных нужд) захотим скрыть кнопочки тех товаров, для покупки которых кредит недостаточен, тогда я прописываю во ViewModel if(Credit < MyPrice) BuyVisible = false — условно говоря. А View у меня биндится к BuyVisible. Или это я поставил в кондицию DelegateCommand такую конструкцию. Но в любом случае эту видимость я задаю вo ViewModel. Модели же, напоминаю, пофиг. Она не продаст, даже если ткнуть в невидимую кнопку.
Спроектировать иначе модель для нужд вью и VM? Если модель используется в проекте в другом месте, если она используется в Вебе и т.д. — перепроектировывать ее для нужд WPF нет необходимости, т.к. именно VM возьмет на себя обязанность спрямить для вьюшки все причудливые изгибы модели.
IsEditVisible — свойства с таким именем во ViewModel быть не должно, ViewModel ничего не знает о видимости по построению.
Слушайте, ну у вас какая-то своя философия MVVM, напишите статью о ней и мы там побеседуем о_0
ViewModel — это не вредная прокладка, а некоторый прочный каркас, к которому прибивается View. Модель может быть такой, облакообразной, как перьевые облака, грозовая бесформенная куча, к которой не прибиндиться, а во ViewModel может быть такой код:
public IsEditVisible { get; } => (_model.SomeProperty[«SomeIndex»] * _model.GetSomeValue) < _model2.AdjustionCorrelator;
Вьюшка не может собрать по модели — отображать ей кнопку Edit, или нет. А вот к VM одному свойству она прибиндиться может.
Я вообще пользуюсь Prism. Там (начиная с пятой версии) View и ViewModel можно связывать по настраиваемому Name Convention, т.е. по определенному шаблону имени. А параметры конструктора VM через dependency injection.
Но вот практический пример: в реквесте один параметр из опционального решили сделать обязательным, обновили базовый образ, автоматом обновили везде package.json, — и вдруг перестал собираться всеми забытый микросервис. Это же прекрасно, что ошибка обнаружилась на этапе компиляции, а не на проде где-то что-то отвалилось и надо искать где и что. Это вот прям жирнейший плюс общего пакета
Отмечу, кстати, что это уменьшение скорее не на 3Гб, — а скорее уменьшение в 20+ раз. Это сильно сказывается, когда приходится обновлять установ на продакшене или тестовом контуре. Одно дело, когда удаленный сервак выкачивает 3 Гб, и совсем другое, когда 0.15 Гб. Да даже не удаленный сервак, а локальное хранилище образов гораздо лучше себя чувствует.
А целиком все микросервисы обновляются периодически. У нас есть npm-пакет с интерфейсами и т.д. общий для всех микросервисов, он обновляется нередко. И каждый раз пушить 3 Гб, а потом тянуть их — так себе
Ээ… Разрабатывают разные команды… и?
На практике вообще не проблема. На практике есть небольшой набор общих для всех микросервисов пакетов, (а конкретно mongoose, axios, nats, express, ..) и некоторым микросервисам нужны специфичные пакеты, которые больше никто не использует.
Например один микросервис отвечает за рендеринг PDF, другой за вебсокеты, третий за связь со сторонним приложением.
Добавить специфичный пакет в базовый образ — не страшно, это никак не отразится на других 19. Обновить свой специфичный пакет (например рендеринга PDF) — опять же, не страшно. Другие 19 он никак не заденет.
Другое дело если пакет общий. Например, если вышла новая мажорная версия mongoose с брейкин ченджем. Тогда либо надо собрать силу волю и команды в кулак — и всем вместе обновится. Либо, если вам так нужна новая фича в монгусе, а других подбить на апдейт не получается — то просто базируете свой микросервис не на общем BaseMS, а на Node по старинке. (но на практике такого не помню)
Повторюсь — добавлять и обновлять специфичные пакеты в базовый образ — не страшно.
Кроме того, в статье кардинальный способ уменьшения вклада каждого микросервиса в общий размер. Только на размер пожатого вебпаком исходника. С трудом представляю, как порезать еще хоть чуть-чуть.
Что касается ObservableCollection, так смысл как раз в том, чтобы она не руками обновлялась Refresh()'ем, а автоматически. Вьшка вся не перестроится — это не веб:) — автоматически произойдет частичное обновление вью, как и задумывалось.
В конкретной программе есть коллекция с динамическим размером — это список покупок пользователя.
Когда я разрабатываю сначала вьюшку, потом к ней создаю VM, а потом, основываясь на вызовах модели из VM, я создаю саму модель — этот подход View-first. Но есть и другой подход (Model-first) — когда сначала без всякого интерфейса создается модель, потом рисуется интерфейс и только потом вьюшки и модель связываются как клеем VM.
Вот вроде говорим об одном… но выводы делаем различные.
Вот допустим у нас в представленной задаче кнопочки с покупками определенных товаров были бы видимы только тогда, когда кредита хватало бы на их покупку.
Модели все равно — видны кнопочки или не видны — даже если вы нажмете на такую кнопку: если денег в кредите недостаточно — модель все равно не продаст вам товар. Теперь, если мы (чисто из визуальных нужд) захотим скрыть кнопочки тех товаров, для покупки которых кредит недостаточен, тогда я прописываю во ViewModel if(Credit < MyPrice) BuyVisible = false — условно говоря. А View у меня биндится к BuyVisible. Или это я поставил в кондицию DelegateCommand такую конструкцию. Но в любом случае эту видимость я задаю вo ViewModel. Модели же, напоминаю, пофиг. Она не продаст, даже если ткнуть в невидимую кнопку.
Я использую Model-first — подход, иногда View-first — подход, но ViewModel-first даже затрудняюсь представить:) Надо посмотреть на сие чудо
Слушайте, ну у вас какая-то своя философия MVVM, напишите статью о ней и мы там побеседуем о_0
В статье просто исправил, а в скачиваемом примере — забыл
public IsEditVisible { get; } => (_model.SomeProperty[«SomeIndex»] * _model.GetSomeValue) < _model2.AdjustionCorrelator;
Вьюшка не может собрать по модели — отображать ей кнопку Edit, или нет. А вот к VM одному свойству она прибиндиться может.