Maui: MVU может быть не тем, что вы думаете

Спасибо @aspnetde , я надеюсь, что вы присоединитесь к нам, пока мы работаем над реализацией этой идеи в течение следующих 18 месяцев или около того. Учитывая вашу историю с MVU, я ожидаю, что вы внесете большой вклад.

Я думаю, что еще слишком рано говорить о том, является ли .NET MAUI MVU или нет, поскольку мы еще не построили его . :)

Да, у нас есть прототип. Да, это вдохновлено экспериментом с кометой. И да, мы знаем, что есть опасения, что то, что мы показали до сих пор, не соответствует общепринятому определению MVU.

Я надеюсь, что мы можем сотрудничать! Если то, что мы в конечном итоге разрабатываем и поставляем, заслуживает другой этикетки, я согласен, что мы должны дать ей такую.

Как вы ожидаете увидеть C# MVU в .NET MAUI?

Какие новые языковые функции вы считаете необходимыми, если таковые имеются?

Можем ли/должны ли мы рассмотреть возможность интеграции Fabulous и/или какие шаблоны имеет смысл сделать общими между C# и F#, а что должно отличаться?

Как вы ожидаете увидеть C# MVU в .NET MAUI?

Вы когда-нибудь слышали, чтобы кто-нибудь говорил C# MVC или C# MVVM? _Model-View-Update_, также известный как _Elm Architecture_, представляет собой четко определенный архитектурный шаблон, а не реализацию, зависящую от языка.

Какие новые языковые функции вы считаете необходимыми, если таковые имеются?

• Хотя типы объединения помогли бы значительно упростить определение сообщений, это можно сделать с помощью интерфейсов/абстрактных классов и подклассов для каждого сообщения, хотя для этого требуется немного больше стандартного кода.
• Для обработки сообщений сопоставление с образцом полезно, если не требуется. Я думаю, что текущее состояние выражений переключения C# уже достаточно для этого, так как форма сообщений будет простой.
• И последнее, но не менее важное: самая важная функция, которую я вижу, — это неизменяемость по умолчанию и включенные сравнения структурного равенства. Насколько я помню текущее предложение записей в C# 9 (также известных как классы данных), они будут обеспечивать именно это.

Таким образом, C# 9, хотя и более шумный, чем F#, с моей текущей точки зрения подходит для использования.

Можем ли/должны ли мы рассмотреть возможность интеграции Fabulous и/или какие шаблоны имеет смысл сделать общими между C# и F#, а что должно отличаться?

Как написано выше, в общем подходе не должно быть ничего особенно специфичного для языка, поскольку сам MVU — это просто архитектурный стиль или модель приложения, как вы это называете.

@TimLariviere Недавно сделал несколько предложений по продвижению Fabulous , которые также включают идеи относительно DSL, более похожего на SwiftUI. Возможно, вы тоже захотите посмотреть и/или поучаствовать там.

Кстати: в прошлом году я провел сравнение 1:1 XF + C# + MVVM и XF + F# + MVU, результаты можно найти здесь, включая исходный код.

Я думаю, что еще рано говорить, что .NET MAUI является или не является MVU

Дело не в том, станет ли MAUI в конце концов MVU. Речь идет об образце в блоге объявлений, который уже вызвал столько путаницы в сообществе. В принципе, я должен предположить, что авторы еще толком не изучали MVU. Разговор о "C# MVU" не делает ситуацию лучше.

Я согласен с @aspnetde и @forki, проблема здесь заключается в общении.

Я думаю, что никто из нас не спорит с тем, чтобы отказаться или изменить вдохновленный кометой C# DSL для MAUI/XF, но даже если мы возьмем то, что до сих пор делается с ним, это все еще использует подчеркивающую концепцию связывания, которая является частью шаблона MVVM. .

Это то, о чем я спрашивал снова и снова в прямом общении, а также в проблемах, возможно, всем участникам стоит прочитать о различных шаблонах, таких как MVVM и MVU.

При этом существует даже способ реализации MVU поверх MVVM, но остается вопрос, какую проблему он решит.

Вы когда-нибудь слышали, чтобы кто-нибудь говорил C# MVC или C# MVVM?

Да, я понимаю, что странно говорить, что за C# или XAML следует архитектурный шаблон вроде MVVM или MVU. Среди более широкого сообщества разработчиков, с которыми я общаюсь, необходимо четко указать, что вы можете использовать любое количество комбинаций в своем проекте. Намерение не состоит в том, чтобы сказать, что «C# MVVM» архитектурно отличается от «XAML MVVM», но что их комбинация возможна, и поэтому опыт разработчика в целом немного отличается.

Я думал, что в этой ветке можно обсудить, как MVU будет выглядеть в .NET MAUI, но, возможно, более продуктивным здесь будет обсуждение того, как мы говорим о множественном опыте разработчиков и шаблонах архитектуры в одном продукте?

Похоже, это направление большинства комментариев здесь, желающих обсудить, что мы называем и обозначаем, и как мы используем термины. Мне бы очень хотелось, чтобы вы высказались по этому поводу, так как я веду большую часть общения и хочу убедиться, что я действительно вношу ясность, а не создаю путаницу.

Речь идет об образце в блоге объявлений, который уже вызвал столько путаницы в сообществе.

Это был мой вклад в блог, и я прошу прощения за путаницу, которую он создал для вас. Я просчитался, добавив ссылки на блог Elm и @aspnetde , в которых мы говорили «вот что такое MVU», и я не ожидал, какой вес фрагмент кода будет иметь для тех из вас, у кого уже есть опыт и ожидания MVU. как это будет/должно выглядеть здесь.

В принципе, я должен предположить, что авторы еще толком не изучали MVU.

У нас были обширные беседы и дебаты на эту тему. Пожалуйста, не предполагайте, и я тоже постараюсь этого не делать.

вопрос остается, какую проблему это решит.

@dersia общая проблема, которую необходимо решить, - предоставить разработчикам выбор. Если вы спрашиваете, что решает MVU поверх MVVM, я понятия не имею — это не то, о чем нас просят, и не то, что мы пытаемся сделать.

Рефакторинг, предложенный в № 28 и № 66, частично касается отделения привязки данных и специфических вещей MVVM от реализаций средства визуализации, так что, если вы выберете MVU, вы не будете использовать дополнительные функции, используемые в MVVM.

Я не ожидал, какой вес будет иметь фрагмент кода

Но это мясо, верно? И мне жаль, что это не соответствовало этикетке.

@давидортинау

Похоже, это направление большинства комментариев здесь, желающих обсудить, что мы называем и обозначаем, и как мы используем термины. Мне бы очень хотелось, чтобы вы высказались по этому поводу, так как я веду большую часть общения и хочу убедиться, что я действительно вношу ясность, а не создаю путаницу.

Я не уверен, что осталось добавить со своей стороны. Думаю, я ясно и ясно выразил свою позицию :-). Если вы собираетесь внедрить MVU, вы будете толкать открытую дверь. Если это то, что можно предположить, взглянув на фрагмент в объявлении и репозиторий Comet, не стесняйтесь делать это, но _пожалуйста_ перестаньте называть это MVU.

Спасибо.

Поскольку Дон упоминался в этой ветке :-) - CC: @dsyme

Я не понимаю, почему это называется MVU, когда это не так. Это может быть отличная парадигма, и она отлично работает здесь — почему бы не придумать подходящий термин, который соответствует парадигме и не сбивает с толку?

@aspnetde что осталось от тебя? Много, я полагаю :).
Я прочитал некоторые части вашей диссертации. Должен сказать, что мне понравилось. Я также читал книгу Дона Сайма о F#. Мне нравится функциональное программирование. По моему опыту, это лаконично, но трудно понять (понять). Удобочитаемость — очень важная часть жизненного цикла разработки. На самом деле много времени уходит на чтение кода. И рекурсия только для записи. Вы можете написать его один раз, но прочитать его почти никто не сможет (аналогично регулярному выражению).
В прошлом я пробовал Redux с Angular во время прототипирования/исследований в компании. Это наполовину эльфийский подход? Это был ценный опыт. Я узнал, что мне нужно следить за тем, чтобы не мутировать состояние, и в результате мне не нужно будет запоминать весь стек, где именно состояние может внезапно измениться.
Я понимаю преимущества неизменности, но я видел презентацию с Эриком Мейером, который внезапно разорвал голову плюшевого мишки, чтобы показать нам, что реальный мир изменчив.

Итак, на что я хотел бы обратить внимание: не противоречит ли наше естественное мышление этим парадигмам? Каков ваш опыт?

У меня большой опыт работы с XAML/C#/MVVM, поэтому мне интересно, почему Дон Сайм считает XAML ненужным.
По моему опыту, это помогает разделить проблемы (пользовательский интерфейс, презентация, бизнес-логика и т. д.). Я не совсем уверен, помогают ли эти DSL (разметки C#) и MVU улучшить качество кода в долгосрочной перспективе. Неопытные/невнимательные разработчики будут смешивать обязанности. Мне также нужно больше опыта работы с шаблоном MVU, чтобы понять его правильно, но вы пробовали обе эти парадигмы, и это очень ценно для всего сообщества.
Пожалуйста, поделитесь как можно больше. Спасибо @aspnetde!

Спасибо (всем) вам большое за понимание

@davidortinau, возможно, здесь произошло недоразумение, я полностью за выбор и оставляю каждому самому выбирать, какой шаблон / парадигму использовать. Я просто пытался сказать, что мы должны правильно называть вещи. Как известно всем, кто занимается разработкой программного обеспечения, давать имена вещам — одна из самых трудных задач, но если уже есть хорошо определенные вещи с именами, мы не должны начинать повторно использовать эти имена для вещей, которыми они не являются.

Мисс общение Недопонимание - одна из самых больших проблем в нашем мире сегодня, я думаю, что как сообщество, как участники проекта, как ведущий проект, мы должны помогать всем в понимании вещей, а также должны быть открыты для критики и признавать ошибки и собираться вместе. исправить это.
В этом случае я думаю, что использование неправильной формулировки должно быть исправлено, и для этого я бы хотел, чтобы этот проект
а) понять, что МВУ - это неправильное название того, о чем мы здесь говорим
и б) найти правильный термин для описания того, что мы пытаемся здесь установить.
а затем c) обновить всех и начать использовать это новое имя

Я думаю, что мы все еще находимся в точке, где мы все еще можем вернуться и исправить это. Давайте сделаем это правильно, худшее, что может случиться, это то, что сообщество XF/Maui понимает MVU как нечто иное, чем остальной мир.

При этом я большой поклонник MVU, и я также люблю MVVM, и я думаю, что беглый подход MVVM (у меня пока нет лучшего имени), как в Comet, и то, что было представлено до сих пор, великолепен и помогает много разработчиков, и я поддержу это, я просто думаю, что мы должны исправить название.

Редактировать: мисс по общению выбыла из конкурса.

Я понимаю преимущества неизменности, но я видел презентацию с Эриком Мейером, который внезапно разорвал голову плюшевого мишки, чтобы показать нам, что реальный мир изменчив.

@tomasfabian это неправильно.

Вы должны начать видеть мир как серию событий, это то, чем он на самом деле является (нет, я не хочу начинать здесь обсуждение источников событий).
С плюшевым мишкой произошло только то, что к его состоянию добавилось новое событие, в данном случае событие "оторвало голову". И, как вы понимаете, после того, как событие произошло, вы не можете вернуться, так как вы не можете просто отменить или удалить то, что произошло. Чтобы вернуть голову мишке, вам понадобится новое событие под названием «пришить голову обратно к телу». 😉

Обсуждение преимуществ или отсутствия FP и MVU здесь, ИМХО, не в тему. Я думал, что эта проблема была просто о возможности недопонимания и точного наименования.

@isaacabraham, возможно, ты прав, и я прошу прощения за это. Это моя вина. Я знаю, что называть вещи важно, но, с другой стороны, заголовок номера звучит так: «MVU может быть не тем, что вы думаете». Так что, надеюсь, это немного более широкая тема, чем называние вещей.
Спасибо, Томас

@tomasfabian Я был бы очень рад поговорить с вами о плюсах и минусах MVU, FP или чего-то еще, реального или воображаемого 😊 Только не думайте, что это подходящий форум для этого.

@давидортинау
Что касается того, какие языковые функции и изменения архитектуры будут полезны, надеюсь, я смогу внести свой вклад с некоторыми предложениями:

* Ключевое слово new и другой синтаксический шум.
В отличие от Dart или Kotlin, C#, вероятно, застрял с обязательным ключевым словом new навсегда, так как сделать его необязательным — это критическое изменение и непопулярное предложение даже в качестве директивы отказа для каждого файла. Таким образом, вместо этого, может быть, официальный (и поддерживаемый) статический класс (или статический класс для пространства имен представления MAUI), содержащий статические методы, которые просто обертывают конструкторы и инициализируют любые свойства только для инициализации, если таковые имеются, по крайней мере, для основного набора Объекты просмотра MAUI. Затем мы можем поместить директиву using static в начало файлов .cs с кодом представления, а затем вызывать методы без синтаксического шума new . Это немного уменьшит беспорядок и шум функций представления C#. Конечно, эти оболочки конструктора статических методов могут быть автоматически сгенерированы сообществом (я сделал что-то подобное для Xamarin.Forms для использования с CSharpForMarkup), но было бы неплохо иметь готовый набор из них, поддерживаемый проект МАУИ.

Кроме того, любые предложения языка C#, которые помогли бы уменьшить синтаксический беспорядок или шум в больших деревьях выражений (как это часто бывает в функциях представления MVU/Comet/CSharpForMarkup), очень помогли бы. C # 9 прошел ДОЛГИЙ путь в этом отношении, чтобы улучшить части M и U MVU, но часть V по-прежнему является проблемой с точки зрения синтаксиса.

* Свойства расширения *
Я знаю, что предложение «расширение всего» пока отложено, но одна вещь, которая может быть полезна для MVVM-с-разметкой C# (например, CSharpForMarkup с Xamarin.Forms), — это свойства расширения. С CSharpForMarkup каждый помощник должен был быть реализован с использованием метода расширения, но в некоторых случаях свойство расширения (которое можно использовать в инициализаторе объекта) выглядело бы намного лучше:

// Instead of this:
public View Body() =>
    new Widget() {
        BuiltInProperty = "initial value",
    }.SetExtensionProperty("initial value");

// the extension property could be included in the object initializer:
public View Body() ->
    new Widget() {
        BuiltInProperty = "initial value",
        ExtensionProperty = "initial value",
    };

Это действительно применимо только к изменяемым деревьям объектов представления, как в MVVM с C# для разметки. Для MVU или других функциональных архитектур пользовательского интерфейса это неприменимо, поскольку объекты представления неизменяемы. В этих случаях метод плавного расширения все же более уместен.

* Будьте менее самоуверенными (или низкоуровневыми, если хотите) в отношении управления состоянием *
Я думаю, что одним из самых больших препятствий для внедрения MVU поверх Xamarin.Forms было отсутствие двух важных компонентов: легковесного графа объектов, который могли возвращать функции представления, который фреймворк мог «рендерить» в реальные компоненты (с их представления для конкретных платформ и т. д.). И вторая часть — это движок сравнения, который эффективно обновляет специфичные для тяжеловесных платформ представления, ища различия между одним возвращаемым значением функции представления и другим, включая способ эффективного выполнения различий путем выполнения частичных различий и т. д.

Похоже, MAUI теперь предоставляет эти два основных элемента, и это здорово! Тем не менее, по крайней мере на поверхностном уровне кажется, что он очень тесно связан с самоуверенным способом управления состоянием, который, по мнению некоторых членов сообщества MVU, ближе к MVVM, чем MVU или аналогичные «функциональные» архитектуры пользовательского интерфейса. Я думаю, что я бы предпочел сохранить две основные части, о которых я упоминал выше (облегченный граф объектов просмотра и эффективный механизм сравнения), и соединить их с системой компонентов более низкого уровня, на которую MVU или Comet можно было бы эффективно наложить поверх, по мнению разработчика. выбор. Может, это уже цель, а я ее не вижу? Если это так, я хотел бы увидеть больше обсуждения этого, по крайней мере, с некоторыми основными примерами.

@aspnetde, почему ты удалил свой пост?

@tomasfabian

По моему опыту, это [MVVM] помогает разделить проблемы (пользовательский интерфейс, презентация, бизнес-логика и т. д.)

Да. У меня есть хороший опыт работы с большими приложениями Xamarin.iOS и Xamarin.Android, созданными с помощью MvvmCross. Хотя сегодня я предпочитаю библиотеки фреймворкам, я думаю, что все эти проекты (некоторые с шестизначным LOC) были успешными как с технической, так и с деловой точки зрения.

Я думаю, что MVVM особенно хорошо справляется с масштабированием приложения. Особенно в мобильных устройствах, где мы вынуждены поставлять монолиты, это помогло нам реорганизовать наши приложения в независимые модули после того, как они достигли определенного размера.

Разве наше естественное мышление не против этих парадигм ([МВУ])? Каков ваш опыт?

Я так не думаю. Возьмите свой опыт работы с Redux для хранилища и представьте, что все ваше приложение извлекает выгоду из его преимуществ. Хотя на первый взгляд он кажется более сложным, по моему опыту, его гораздо проще понять и с ним работать. Как часто указывает @forki , это почти скучно, потому что однонаправленный поток данных постоянно дает понять, что происходит.

Я не совсем уверен, помогают ли эти DSL (разметки C#) и MVU улучшить качество кода в долгосрочной перспективе.

Хотя и MVU, и MVVM имеют разные преимущества, у обоих есть и разные недостатки.

Несмотря на то, что наши проекты MVVM считались успешными, мы с моей командой немного растерялись из-за их отладки. В частности, в одном проекте мы начали страдать от сложности, вызванной отсутствием опыта у новых членов команды и непониманием – как вы уже указали. Я думаю, что это менее вероятно в MVU, когда применяется строго, потому что он определяет границы того, как вещи работают так узко, что почти труднее вырваться из этого и построить что-то неправильно, чем наоборот.

Для МВУ я вижу две основные проблемы. Первое: Масштабирование. Многие выступают за единую программу. Я настроен скептически (и думаю, что несколько программ/модулей было бы лучше). Во-вторых: прямо сейчас такая вещь, как Fabulous, находится поверх Xamarin.Forms. Итак, это слой абстракции поверх слоя абстракции поверх слоя абстракции поверх iOS/Android. Это огромная сложность. Таким образом, вы не только имеете дело с нерешенными ошибками, которые никого не волнуют, но также более или менее утомительной и неприятной работой является обновление одного уровня абстракции (Fabulous) при изменении другого (Xamarin.Forms).

Вот где я вижу большие шансы для MAUI. Честно говоря, мне бы очень хотелось, чтобы мейнтейнеры Fabulous объединились здесь с Microsoft. И я очень надеюсь, что Microsoft не разрушит его, как это делали другие части организации в прошлом.

Томас

Когда я на днях читал официальный анонс , то удивился тому, что там представлено как МВУ:

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

Насколько я понимаю, это не МВУ . Некоторые мысли о том, почему я так думаю, я уже записал здесь .

Дон Сайм, который, как я понимаю, несколько месяцев 2018 года потратил на внедрение MVU поверх Xamarin.Forms и построение того, что впоследствии стало Fabulous , немного более дипломатичен , но суть та же.

Итак, в чем моя точка зрения?

• Я хотел бы, чтобы вы реализовали настоящий архитектурный шаблон, независимо от того, на C# или F#. Здесь можно начать с общения с людьми, стоящими за Fabulous.
• Если вы не заинтересованы в этом, но у вас есть четкое представление о том, как построить то, что доступно сегодня в виде библиотеки Comet , то, пожалуйста, рассмотрите возможность использования более подходящего имени для этой «модели приложения». Изобретайте что-то новое. Назовите его МСМВУ. Что бы ни. Но не продавайте яблоки за апельсины.

Ваше здоровье!

Почему они назвали его МСМВУ? Комета была МВУ, такой и останется. А Мауи - это МВУ.

Я думаю, что еще рано говорить, что .NET MAUI является или не является MVU

Дело не в том, станет ли MAUI в конце концов MVU. Речь идет об образце в блоге объявлений, который уже вызвал столько путаницы в сообществе. В принципе, я должен предположить, что авторы еще толком не изучали MVU. Разговор о "C# MVU" не делает ситуацию лучше.

Никакой путаницы это не вызывает. Просто некоторые люди не могут справиться с этим, видя, как С# выполняет MVU.

Что бы это ни стоило, SwiftUI (из которого Comet черпает большую часть своего вдохновения) имеет тенденцию называть свой шаблон MVVM, хотя явных указаний нет.
Я не нашел ни одного упоминания о MVU.

@TimLariviere https://github.com/Clancey/Comet#key -concepts
По сути, Comet назвал это MVU и уже упускает из виду цикл сообщений, который мы имеем в более старых определениях MVU.

Что бы это ни стоило, SwiftUI (из которого Comet черпает большую часть своего вдохновения) имеет тенденцию называть свой шаблон MVVM, хотя явных указаний нет.

Это даже не так, если посмотреть на пример в начале этого поста здесь: https://nalexn.github.io/clean-architecture-swiftui/

Я не нашел ни одного упоминания о MVU.

В том же посте это также кратко обсуждается (как комбинация SwiftUI + Redux = TEA). Хотя тогда он принимает странный оборот к «Чистой архитектуре» 😄

Поскольку меня здесь упомянули, скажу лишь несколько вещей.

• Я думаю, что MAUI великолепен, и я думаю, что изучение MVU как архитектуры может быть полезно для людей, чтобы понять MAUI.

• Легко зацикливаться на словах, и нам, вероятно, следует сделать передышку и постараться не беспокоиться об этом на данном этапе, так как есть достаточно времени, чтобы скорректировать используемые слова, и я думаю, что сообщение о точной терминологии было слышал. Лично я думаю, что Elm установил, что неприукрашенное, безоговорочное использование «MVU» означает явные сообщения, явное обновление, функциональные модели, пересчет функционального представления и дифференциальное обновление. Но существует множество вариаций MVU, и MAUI является одной из точек в этом спектре (который охватывает весь путь до MVVM как своего рода инкрементируемой вручную системы обработки сообщений с неявным, всепроникающим изменяемым состоянием). Связь SwiftUI интересна с этой точки зрения.

• Я замечаю, что у людей, как правило, очень сильные убеждения и мнения в этой области, и они могут принимать вещи очень близко к сердцу. Я знаю, на что это похоже, и, как и в случае с дизайном языка программирования, я думаю, что у всех точек зрения есть свои плюсы и минусы. Я призываю всех пробовать, использовать, учиться, делиться и работать вместе, чтобы создать наилучший набор технологий.

@dsyme
Я думаю, что правильным термином для архитектуры Comet/MAUI является вариант однонаправленного потока данных (или UDF), но не MVU, поскольку MVU сам по себе является очень специфическим вариантом UDF. MAUI/Comet, безусловно, квалифицируется как инфраструктура UDF (как и SwiftUI), но не квалифицируется как инфраструктура MVU. Существует несколько вариантов UDF, включая MVU, Flux, Redux, React и т. д., но неправильно называть Comet MVU, когда это вовсе не MVU.

В отличие от MVU модель является изменяемой и изменяется кодом в функции просмотра. Затем наблюдаются мутации, и представления реагируют на эти мутации повторным рендерингом. Он по-прежнему однонаправленный, потому что представления не изменяются, но нет функции обновления, нет сообщений и нет диспетчеризации сообщений — таким образом, не MVU. Это ближе к однонаправленному варианту MVVM.

@JeroMiya Спасибо, у вас есть ссылка на эту терминологию?

@dsyme У меня нет конкретной ссылки на него, но я впервые услышал этот термин, который использовался в первые дни React, особенно в отношении самого React и нескольких появившихся ранних шаблонов, таких как Redux и Flux. Я помню статью, в которой описывалось несколько вариантов UDF (в основном в пространстве React), но сейчас не могу найти.

При этом это не формальная архитектура - больше похоже на базовую концепцию представления, являющегося функцией модели, в отличие от представления, являющегося деревом объектов с состоянием, которое мутирует в ответ на события. Концепция UDF не обязательно указывает, как модель обновляется или является ли она изменяемой или неизменной. MVU расширяет концепцию UDF не только на само представление, но и на процесс обновления модели. Таким образом, в MVU модель также является неизменной, а изменения состояния пользовательского интерфейса представлены в виде команд, которые создают новые модели, которые запускают новые представления.

Конечно, это не новая концепция — даже до появления React большинство серверных веб-фреймворков, таких как Asp.Net MVC, Rails и даже PHP, технически считались однонаправленными. Это просто не было обычным явлением для основных фреймворков SPA и фреймворков пользовательского интерфейса на стороне клиента до появления React.

@dsyme У меня нет конкретной ссылки на него, но я впервые услышал этот термин, который использовался в первые дни React, особенно в отношении самого React и нескольких появившихся ранних шаблонов, таких как Redux и Flux. Я помню статью, в которой описывалось несколько вариантов UDF (в основном в пространстве React), но сейчас не могу найти.

При этом это не формальная архитектура - больше похоже на базовую концепцию представления, являющегося функцией модели, в отличие от представления, являющегося деревом объектов с состоянием, которое мутирует в ответ на события. Концепция UDF не обязательно указывает, как модель обновляется или является ли она изменяемой или неизменной. MVU расширяет концепцию UDF не только на само представление, но и на процесс обновления модели. Таким образом, в MVU модель также является неизменной, а изменения состояния пользовательского интерфейса представлены в виде команд, которые создают новые модели, которые запускают новые представления.

Конечно, это не новая концепция — даже до появления React большинство серверных веб-фреймворков, таких как Asp.Net MVC, Rails и даже PHP, технически считались однонаправленными. Это просто не было обычным явлением для основных фреймворков SPA и фреймворков пользовательского интерфейса на стороне клиента до появления React.

@JeroMiya спасибо за это, именно так я понимаю MVU.
Я бы даже сказал, что одним из старейших и до сих пор широко используемых приложений, использующих и демонстрирующих MVU в лучшем виде, является MS Excel.

@dsyme, читая ваши комментарии, у меня
Пожалуйста, объясните мне, что это не то, что вы понимаете под MAUI, или если это так.
Насколько я понимаю, MAUI — это всего лишь следующий MS Application Framework, который когда-нибудь в будущем заменит XF.

Мне очень нравится, как обстоят дела с этим выпуском и комментариями к нему. Спасибо всем за участие. Возможно, вместе мы сможем создать и правильно назвать все различные архитектуры как возможные разновидности MAUI.

@dersia Спасибо! Просто примечание из моего собственного опыта работы с CSharpForMarkup: это немного более низкий уровень, чем MVVM, — это скорее набор методов расширения и утилит, делающих разметку C# более упорядоченной и привлекательной. Вы, безусловно, можете реализовать с ним шаблон MVVM, поскольку у него есть помощники, облегчающие привязку ViewModel, но в итоге я реализовал всю логику моего представления в Redux вместо ViewModels. Просто нужно добавить несколько методов расширения для привязки свойств представления к селекторам состояния, которые составляют всего Func<StateType, ChildStateType> Я перехожу к операторам Select и DistinctUntilChanged в хранилище состояний Redux, которое Observable<StateType> . Не совсем однонаправленный поток данных, но у меня не было зрелого способа делать различия между деревом объектов пользовательского интерфейса и функциями просмотра, как это делает сейчас Fabulous.

Некоторое время назад полиция ОТДЫХА пыталась впихнуть нам в глотку, что мы все не должны называться ОТДЫХОМ. Все до сих пор называют это ОТДЫХОМ, и мы все живы и здоровы. 😉

@bitbonk сообщество REST добавлялось все больше и больше вещей. Теперь они используют «гипермедиа» для обозначения передачи репрезентативного состояния. REST сегодня на самом деле означает только «не SOAP» или «JSON через HTTP», ни один из которых не может передать свою основную идею. Комментаторы здесь надеются избежать той же участи для MVU.

@davidortinau @tomasfabian , мне еще предстоит увидеть пример MVU на MAUI. Я постараюсь разработать пример сегодня вечером. Я только что сделал что-то подобное для WinForms здесь . Я предполагаю, что это не должно быть слишком сложно.

@JeroMiya Спасибо, у вас есть ссылка на эту терминологию?

@dsyme , я думаю, что это произошло с React Flux, но они указывали на игровые архитектуры, то есть на Doom 3. Кажется, я помню, как обсуждал это с @TIHan, когда он был впервые представлен.

• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/однонаправленный поток данных

Вот моя попытка примера C#. У меня нет MAUI, чтобы попробовать это в качестве реального примера. Там нет превью, не так ли? Во всяком случае, это грубый перевод идеи.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Я однажды вкратце попробовал что-то подобное , за исключением части представления. С выходом Records на C# 9 это станет еще более разумным.

Я относительно новичок в MVU, и у меня, вероятно, очень мало опыта его использования по сравнению со многими из вас. Но концепции MVU определенно привлекли мой интерес, и мне это нравится. Я очень рад видеть, что разработчикам C# предоставлена ​​структура, помогающая развиваться по шаблону MVU.

Я полностью согласен с тем, что MAUI MVU не является типичным MVU, и на него огромное влияние оказывает SwiftUI. Его главный автор Клэнси Хаймеслеф очень ясно объяснял это почти на всех своих сеансах. Мы все знаем, что Redux находится под сильным влиянием MVU, как и SwiftUI, Flutter и многие другие фреймворки. Ни один из них не является чистым MVU.

Но я уверен, мы все согласны с тем, что наиболее близким архитектурным паттерном для всех этих фреймворков является MVU. Вот почему люди ссылаются на него. И помните, мы говорим о названии блога для фреймворка, который будет выпущен через полтора года.

И если вы скажете, что люди злятся из-за этого заголовка блога. Я не думаю, что мы должны действительно беспокоиться о них. Сообщество все еще должно продолжаться. Давайте потратим нашу энергию, чтобы сделать этот фреймворк лучше. Не слишком беспокойтесь о мелких деталях.

Но я уверен, мы все согласны с тем, что наиболее близким архитектурным паттерном для всех этих фреймворков является MVU. Вот почему люди ссылаются на него.

Собаки, лошади, кошки и шимпанзе очень близки друг другу. С этого момента я буду называть их всех кошками.

:) Ну вы не должны. Но позвольте мне сказать вам кое-что: кошки, тигры, леопарды и т. д. называются кошками. И я рад, что вы это подняли. Потому что здесь именно так.

@aspnetde : Томас, с

@ libin85 проблема именно в этом. Вы начали перечислять вещи, которые на самом деле относятся к одной категории, и проигнорировали то, что не принадлежит. Помещая образец MAUI в категорию MVU, вы фактически помещаете шимпанзе в категорию кошек.

Это сходство с реализациями MVU, например, неизменное представление. Но есть явные различия, например, нет цикла сообщений и явной функции обновления. Модель мутируется прямо в представлении. Это то, чего люди явно не хотели, когда придумали MVU. В некоторых языках это было бы даже невозможно — поэтому и появился MVU. И почему он стал популярным. Теперь нам следует быть осторожными, если мы удалим эти свойства из нашего определения MVU.

@forki : я не против того, что ты сказал. На самом деле это те моменты, которые вы подняли в последнем комментарии, которые нам нужно обсудить как сообщество, а не заголовок в сообщении в блоге. Это моя точка зрения. Это положительный момент для обсуждения, и структура выиграет от этого.

Я согласен, что название — это маленькая деталь, которая не должна отвлекать от более важных аспектов. Однако причина, по которой я поднял этот вопрос, заключается в том, что лично я не рассматриваю MAUI как усилия сообщества, где здравый смысл в конечном итоге приведет к общепризнанному решению. Это продукт Microsoft, где окончательные решения принимаются за закрытыми дверями. Я здесь в качестве клиента, чтобы высказать свои опасения.

Но я уверен, мы все согласны с тем, что наиболее близким архитектурным паттерном для всех этих фреймворков является MVU.

@ libin85 Я не согласен, что это самый близкий архитектурный образец. MVU — это набор ограничений для того, что в целом выглядит как MVP или Model View Presenter. MVVM похож, но берет другое направление, поскольку его Presenter представляет собой ViewModel с привязками данных. Сам MVP является ограниченной формой MVC. Я думаю, что можно с уверенностью сказать, что все они являются потомками MVC и даже MVP, но сказать, что MVU применим к SwiftUI, Flux и т. д., значит сделать MVU бессмысленным термином.

Я согласен, что название — это маленькая деталь, которая не должна отвлекать от более важных аспектов.

Нет, имена важны. Их трудно как установить, так и сохранить их значение. См. также REST, о котором я говорил выше. ОТДЫХОМ настолько злоупотребляют, что он больше не имеет смысла, кроме как термин маркетингового жаргона. Я бы не хотел, чтобы это произошло с MVU, особенно когда существуют условия для того, что предоставляет MAUI «MVU».

Что бы это ни стоило, я думаю, что MAUI «MVU» — хорошая альтернатива варианту MVVM. Как и в случае с REST, вам не нужно делать какие-то определения, чтобы сделать что-то полезное и хорошее. Только, пожалуйста, не засоряйте имя альтернативами, которые явно отклоняются от четко определенного и установленного шаблона. В конце концов, MVU _также_ будет хорошей альтернативой вариантам MVVM и Comet.

Что бы это ни стоило, я думаю, что MAUI «MVU» — хорошая альтернатива варианту MVVM. Как и в случае с REST, вам не нужно делать определение, чтобы сделать что-то полезное и хорошее, просто, пожалуйста, не засоряйте имя альтернативами, которые явно отклоняются от его определения.

ПОЛНЫЙ ПОДТВЕРЖДЕНИЕ.

Почему они назвали его МСМВУ? Комета была МВУ, такой и останется. А Мауи - это МВУ.

@saint4eva они «продаются» как MVU, но не по определению.

Я согласен, что название — это маленькая деталь, которая не должна отвлекать от более важных аспектов.

Нет, имена важны. Их трудно как установить, так и сохранить их значение. См. также REST, о котором я говорил выше. ОТДЫХОМ настолько злоупотребляют, что он больше не имеет смысла, кроме как термин маркетингового жаргона. Я бы не хотел, чтобы это произошло с MVU, особенно когда существуют условия для того, что предоставляет MAUI «MVU».

Что бы это ни стоило, я думаю, что MAUI «MVU» — хорошая альтернатива варианту MVVM. Как и в случае с REST, вам не нужно делать какие-то определения, чтобы сделать что-то полезное и хорошее. Только, пожалуйста, не засоряйте имя альтернативами, которые явно отклоняются от четко определенного и установленного шаблона. В конце концов, MVU _также_ будет хорошей альтернативой вариантам MVVM и Comet.

Я согласен с большей частью того, что вы сказали, но я думаю, что «Maui MVU» все еще такой же плохой и запутанный. Я бы, наверное, выбрал «Maui MVP» или MVC. Оба работают и ближе к тому, что представлено в блоге, чем MVU.

Редактировать добавить:
Я даже не уверен, где живет предложенная версия. Я имею в виду, что логика в MVVM находится в ViewModel, в MVU — в функции обновления, в MVP — в Presenter, а в MVC — в контроллере.

Будет ли представление, в котором живет все? Или все это живет в каком-то классе, названном моделью предметной области, который служит представлению, логике и модели? Должны ли модели быть отдельными классами (типами) или записями?

Я думаю, что это для меня главная проблема здесь, я понятия не имею, как это «представлено», и поэтому я не вижу функции обновления, модели и просмотра.

Из коробки мне кажется, что MAUI находится на более низком уровне, чем шаблоны, обсуждавшиеся до сих пор — на самом деле это просто модель (или состояние) и часть представления этих других шаблонов. Что-то, что вы, возможно, могли бы использовать для реализации этих других шаблонов (хотя управление состоянием немного самоуверенно).

Так, например, если T в State<T> является классом, подобным ViewModel, и вы добавляете отдельный набор классов модели данных, то в итоге вы получите что-то вроде MVVM с однонаправленный вид.

С другой стороны, если вы добавите Redux-подобную систему управления состоянием и подключите модель состояния Redux в качестве T в State<T> , то в итоге вы получите что-то очень близкое к MVU. , хотя и не так полностью интегрирован, как традиционный MVU, такой как Elm/Fabulous. Может быть, вы могли бы скрыть представления MAUI за инфраструктурой MVU, как это делает Fabulous с Xamarin.Forms?

Я не уверен, как бы вы реализовали шаблон MVC или MVP поверх MAUI. В качестве грубого первого прохода я думаю, что, может быть, вы создали отдельный класс, который предоставляет «действия» функции просмотра. Например, предположим, что у вас есть диалоговое окно подтверждения MAUI, а ваш класс «контроллер» имеет метод «ClickOK» и метод «ClickCancel». Представление MAUI будет перенаправлять события кликов из представления в контроллер, который либо создаст новую модель, либо изменит существующую модель.

@JeroMiya Я согласен, определенно использование шаблона Redux может приблизить его к MVU и сделать архитектуру менее категоричной. Я счастливый пользователь React-Redux, React-Hooks, ReactiveX и в последнее время приложений Blazor :heart: Fluxor :heart: . @mrpmorris может внести свой вклад в этот разговор.

Вот моя попытка примера C#. У меня нет MAUI, чтобы попробовать это в качестве реального примера. Там нет превью, не так ли? Во всяком случае, это грубый перевод идеи.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Приведет ли это к большему снижению производительности для обновлений, чем в образце Microsoft? В этой модели, насколько я понимаю, будет создан экземпляр нового представления, содержащего все элементы пользовательского интерфейса, в отличие от образца MS, оставляющего существующие элементы представления на месте и просто обновляющего значение метки (необходимое любое изменение). -размерная стоимость, которую это могло бы иметь).

Это различие, по-видимому, является одним из основных отличий, лежащих в основе этого обсуждения именования, и поэтому мне любопытно, существуют ли в традиционно определенной архитектуре MVU другие технологии для эффективного обновления пользовательского интерфейса, и если да, то реализованы ли они на уровне движок рендеринга?

@markmccaigue в отношении производительности: часто системы MVU поставляются с виртуальным представлением (или виртуальным DOM в случае html) и механизмом сравнения. Таким образом, после сравнения DOM с виртуальным DOM фреймворку нужно только применить патч к DOM. Обычно это очень эффективно, особенно если вы работаете с неизменяемыми структурами данных.

Привет!!

Я собираюсь закрыть эту проблему на данный момент. Я хотел бы обсудить это, но github не хочет, чтобы это работало :-/

Если кто-то хочет продолжить этот разговор, пожалуйста, создайте элемент обсуждения, а затем сошлитесь на эту проблему.