Ваш подход хороший, т.е. кейс где Вы сделали на каждый "похожий но немного другой" отдельный компонент который внутри собирает нужный вид с нюансами. Проблемы у такого похода начинаются когда требуется совместить или использовать две и более модели которые вроде как обычно не связаны друг с другом но вот в каком-то одном месте они связаны и друг от друга зависят (внешний вид зависит). Мы можем объединить по этому же принципу в один компонент но он будет принимать уже не одну модель а n моделей что вполне может приводить к ситуации как Выше в статье мы вроде вынесли и собрали в одном месте но пропов (моделей) у него много для его настройки. Эту ситуацию можно допустим решить изменением структуры ответа у бекэнда на содержащую общую модель но не всегда это резонно и возможно, особенно если данные уже есть на стороне фронта смысла допустим получать их еще раз нет. Второе неудобство у данного подхода в том что если допустим я имею десять таких компонентов и что-то меняться фундаментально то в них во всех (или как минимум в большинство) придется зайти и что-то поменять. Я думаю что подход к разделению компонентов не может быть один, надо применять разные в зависимости от разных кейсов для применения компонентов. У нас в команде используется несколько разных подходов в том числе и все которые Вы описали в статье. Помимо них есть например еще подход когда компонент с бизнес логикой выноситься отдельно а компонент с представлением не содержит логики вообще. Вот пример кнопку мы разделили на два компонента один содержащий логику и состояние https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/states/ButtonState.vue и второй содержащий представление https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/views/material/MaterialButtonView.vue Суть такого подхода в том что можно без изменения компонента с бизнес логикой тасовать компоненты с его представлениями коих может быть много. Пример с кнопкой когда у нас логика нажатия и обработчик кнопки одинаковый у всех кнопок но выглядеть она может в разных частях системы по разному и для каждого представления будет свой компонент но без логики. Вот тут можно посмотреть пример как это склеить воедино https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/examples/helloworld/ButtonsDemo.vue Пример для кнопки но его можно натянуть и на бизнес логику.
В Steam-е моя карта visa была удалена, а на все остальные варианты написано сообщение "В данный момент покупка с помощью выбранного способа оплаты невозможна. Приносим извинения за доставленные неудобства."
Серьёзно? Как минимум у нас и в контексте WPF везде натыкаешься на одно и тоже.
Я работал на нескольких проектах и на них использовались Prism, MVVM Light, Caliburn.Micro, MvvmCross, ReactiveUI, Cinch в остальных были свои велосипеды. Тут еще стоит упомянуть что хоть все они и решали одну и ту же проблему но делали это со своими ньюансами. Т.е. просто пересесть с одной на другую поменяв названия методов не представляется возможным. Незнаю может это мне так повезло...
Проблема WPF/UWP технологий я думаю в том что нет развития XAML-а как декларативного языка. Система привязки и MVVM дак вообще не развивается. Из последних инноваций только x:Bind можно вспомнить и то это для очень узких кейсов. Нет сильной готовой библиотеки от Microsoft для этого. По сути они вообще не развивают это направление, в голом проекте тебе надо самому буквально с нуля делать реактивность. Из-за чего и получилось что какие-то конторы делают свои велосипеды, другие делают библиотеки количество которых слава богу не приближается к таковым в JavaScript но все равно очень большое и самое главное в них авторы по разному представляют как что должно работать. Т.е. например переходя с одной работы на другую вероятность там встретить похожую библиотеку или вообще какую-нибудь знакомую тебе опенсорсную крайне мала. А система привязок к сожалению очень сильно сдает, если хотя бы раз делать реактивность на JS с библиотеками вроде Vue.js/Angular/etc когда прямо в шаблоне можно просто написать property1 > property2 ? "value1" + property3 : "value2" то возвращаясь к конвертерам и простыне по типу "this.OneWayBind(ViewModel, vm => vm.Series, v => v.Plot.Series) .DisposeWith(disposable); " становится очень грустно. На маленьких и ближе к средним проектах это впринципе не особо заметно но когда проект большой все эти недостатки начинают сильно бить по скорости разработки и негативно сказывать на объеме кода. Мне кажется что развитием было бы либо замена XAML на что-то новое менее многословное либо как поступили в Asp.Net придумав Razor который позволяет писать Html с динамическими вставками, также круто было бы если бы можно было писать XAML с вклиниванием C# которым было бы легко генерить некоторые куски код.
Много бойлерплейт-кода: создать HTTP-клиент, HTTP client factory, договориться о сериализации (JSON, XML или другие варианты), учесть различные форматы дат, чисел и так далее, кейсинг. Соответственно, много возможностей для возникновения ошибок — нужно писать DTO-классы специально для транспорта.
gRPC тоже не является серебрянной пулей которая это целиком решает. Например использование nullable типов в C# может выстрелить когда какой-нибудь клиент захочет его использовать из языков где нет nullable типов. Незнаю как сейчас но раньше decimal не поддерживался что требовало создание своего типа который после передачи надо было склеивать в родной тип decimal на стороне внешнего клиента и в обратную сторону аналогично.
Я конечно не спец по биндингу для языка Python но сама технология Qt поддерживает дополнительный подход к разработке интерфейса в виде использования декларативного языка QML. На него хорошо ложится разделение логики и UI и возможно использование различных паттернов типа MVVM. Единственный недостаток который есть у этой технологии если нужен прям родной нативный UI из системы то она к сожалению такого не предоставляет.
Меня всегда интересовало зачем взяли такой тяжеловесный язык как C# в качестве скриптового языка для игрового движка, когда можно было взять что-то более простое вроде Lua или Python. С одной стороны понятно что можно использовать библиотеки из мира C# но вот читая такие статьи у меня складывается впечатление что разработчики библиотек могут и не знать о таких нюансах и вовсю использовать linq, foreach и прочие влияющие на производительность вещи. А с другой стороны если для него надо писать "свой" Linq и бороться за каждую сборку мусора то стоит ли игра свеч?
Ваш подход хороший, т.е. кейс где Вы сделали на каждый "похожий но немного другой" отдельный компонент который внутри собирает нужный вид с нюансами. Проблемы у такого похода начинаются когда требуется совместить или использовать две и более модели которые вроде как обычно не связаны друг с другом но вот в каком-то одном месте они связаны и друг от друга зависят (внешний вид зависит). Мы можем объединить по этому же принципу в один компонент но он будет принимать уже не одну модель а n моделей что вполне может приводить к ситуации как Выше в статье мы вроде вынесли и собрали в одном месте но пропов (моделей) у него много для его настройки. Эту ситуацию можно допустим решить изменением структуры ответа у бекэнда на содержащую общую модель но не всегда это резонно и возможно, особенно если данные уже есть на стороне фронта смысла допустим получать их еще раз нет. Второе неудобство у данного подхода в том что если допустим я имею десять таких компонентов и что-то меняться фундаментально то в них во всех (или как минимум в большинство) придется зайти и что-то поменять. Я думаю что подход к разделению компонентов не может быть один, надо применять разные в зависимости от разных кейсов для применения компонентов. У нас в команде используется несколько разных подходов в том числе и все которые Вы описали в статье. Помимо них есть например еще подход когда компонент с бизнес логикой выноситься отдельно а компонент с представлением не содержит логики вообще. Вот пример кнопку мы разделили на два компонента один содержащий логику и состояние https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/states/ButtonState.vue и второй содержащий представление https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/views/material/MaterialButtonView.vue Суть такого подхода в том что можно без изменения компонента с бизнес логикой тасовать компоненты с его представлениями коих может быть много. Пример с кнопкой когда у нас логика нажатия и обработчик кнопки одинаковый у всех кнопок но выглядеть она может в разных частях системы по разному и для каждого представления будет свой компонент но без логики. Вот тут можно посмотреть пример как это склеить воедино https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/examples/helloworld/ButtonsDemo.vue Пример для кнопки но его можно натянуть и на бизнес логику.
Можете пояснить что это значит? Как подход отпочковался от шаблона и в чем этот подход заключается?
В Steam-е моя карта visa была удалена, а на все остальные варианты написано сообщение "В данный момент покупка с помощью выбранного способа оплаты невозможна. Приносим извинения за доставленные неудобства."
Я работал на нескольких проектах и на них использовались Prism, MVVM Light, Caliburn.Micro, MvvmCross, ReactiveUI, Cinch в остальных были свои велосипеды. Тут еще стоит упомянуть что хоть все они и решали одну и ту же проблему но делали это со своими ньюансами. Т.е. просто пересесть с одной на другую поменяв названия методов не представляется возможным. Незнаю может это мне так повезло...
Проблема WPF/UWP технологий я думаю в том что нет развития XAML-а как декларативного языка. Система привязки и MVVM дак вообще не развивается. Из последних инноваций только x:Bind можно вспомнить и то это для очень узких кейсов. Нет сильной готовой библиотеки от Microsoft для этого. По сути они вообще не развивают это направление, в голом проекте тебе надо самому буквально с нуля делать реактивность. Из-за чего и получилось что какие-то конторы делают свои велосипеды, другие делают библиотеки количество которых слава богу не приближается к таковым в JavaScript но все равно очень большое и самое главное в них авторы по разному представляют как что должно работать. Т.е. например переходя с одной работы на другую вероятность там встретить похожую библиотеку или вообще какую-нибудь знакомую тебе опенсорсную крайне мала. А система привязок к сожалению очень сильно сдает, если хотя бы раз делать реактивность на JS с библиотеками вроде Vue.js/Angular/etc когда прямо в шаблоне можно просто написать property1 > property2 ? "value1" + property3 : "value2" то возвращаясь к конвертерам и простыне по типу "this.OneWayBind(ViewModel, vm => vm.Series, v => v.Plot.Series) .DisposeWith(disposable); " становится очень грустно. На маленьких и ближе к средним проектах это впринципе не особо заметно но когда проект большой все эти недостатки начинают сильно бить по скорости разработки и негативно сказывать на объеме кода. Мне кажется что развитием было бы либо замена XAML на что-то новое менее многословное либо как поступили в Asp.Net придумав Razor который позволяет писать Html с динамическими вставками, также круто было бы если бы можно было писать XAML с вклиниванием C# которым было бы легко генерить некоторые куски код.
gRPC тоже не является серебрянной пулей которая это целиком решает. Например использование nullable типов в C# может выстрелить когда какой-нибудь клиент захочет его использовать из языков где нет nullable типов. Незнаю как сейчас но раньше decimal не поддерживался что требовало создание своего типа который после передачи надо было склеивать в родной тип decimal на стороне внешнего клиента и в обратную сторону аналогично.
Я конечно не спец по биндингу для языка Python но сама технология Qt поддерживает дополнительный подход к разработке интерфейса в виде использования декларативного языка QML. На него хорошо ложится разделение логики и UI и возможно использование различных паттернов типа MVVM. Единственный недостаток который есть у этой технологии если нужен прям родной нативный UI из системы то она к сожалению такого не предоставляет.
Меня всегда интересовало зачем взяли такой тяжеловесный язык как C# в качестве скриптового языка для игрового движка, когда можно было взять что-то более простое вроде Lua или Python. С одной стороны понятно что можно использовать библиотеки из мира C# но вот читая такие статьи у меня складывается впечатление что разработчики библиотек могут и не знать о таких нюансах и вовсю использовать linq, foreach и прочие влияющие на производительность вещи. А с другой стороны если для него надо писать "свой" Linq и бороться за каждую сборку мусора то стоит ли игра свеч?