Часть этих кошельков контролируется биржами и фондами, но биткоины принадлежат их клиентам, которых гораздо больше.
Как я понимаю, в исследовании это учитывается (страница 5 статьи)
Determining the concentration of ownership is more complicated than just tracking the holdings of the richest addresses, since many of the largest addresses belong to cold wallets of exchanges and online wallets, which hold Bitcoin on behalf of many investors. We develop a suite of algorithms based on graph analysis to classify addresses into those belonging to individual investors or those belonging to intermediaries.
Если честно, то у меня сложилось мнение, что у вас какое-то особое представление о MVVM. Возможно, что в нативном Android, он действительно имплементрован как-то по-особенному (а вы ссылаетесь именно на Android). Я вам советую почитать о нем на сайте Microsoft.
Почему это VM говорит диалогу появиться вместо того, чтобы поставить isDialogVisible = true
Да потому что как вам выше уже писали, диалоги управляются менеджером диалогов. Просто вам такой подход не понравился, и вы искренне считаете, что созданием и отресовкой диалога должна заниматся именно та страница, на которой он вызван.
это точно такая же часть UI, как кнопка, label и т.д.
Не совсем точно такая же. На мобильных устройствах диалоги, чаще всего (хотя теоретически не обязательно), перекрывают весь экран и блокируют страницу. При этом, вы (как правило) видите только один диалог. Бывают ситуации, когда диалоговое окно надо показать на уровне вашего приложения (может прилетела ошибка из другой части программы). Но показывать два диалога одновременно - будет странно. Значит вам все равно надо что-то, что управляет ими всеми. И тогда вы тащите новые зависимости в ваше вью. Можно это делать? Технически - конечно. Но тогда ваше вью все разростается и разростается.
Но диалоги - это лишь частный пример. Вам просто не нравится идея, что если какая-то логика принадлежит UI, то она может быть где-то еще. Лично я не вижу в этом никаких проблем, так как есть четкая структура. Нет никакой сложности в понимании, где находить в вашем коде именно структуру UI, а где его логика. Добавляет ли это код - да... несколько строк в отдельном файле, и все.
Между прочим, у вас вообще нигде не сказано за binding. А между прочим - это одна из ключевых характеристик паттерна. Еще раз советую побольше о нем почитать.
Если вы искренне уверены, что предложенная вами архитектура более рациональна, возможно лучше представлять ее публике в чистом виде, а не под соусом, что MVVM - антипаттерн. Я бы также подумал над лучшими примерами. Предложенные в статье лично меня не переубеждают.
Диалог - это часть UI, полноправная. Но мы же тут не говорим об изменении любого UI в вашем приложении. Мы говорим об изменении конкретной страницы. А в этом случае она останется такой же.
вью про это не в курсе
А зачем вашей вью (именно экрану, где располагается кнопка выхода), знать о наличии этого диалога (это и есть, кстати, пример tight coupling)? В данном конкретном случае, нажатие на кнопку Выйти просто запускает процесс выхода. А как вы структурируете этот процесс - это другое дело. Представьте, что этот процесс состоит из нескольких стадий, или с разными опциями, возможно он требует дополнительной бизнес-логики, и все эти стадии и опции никак не влияют на тот экран с кнопкой выйти.
Собсвенно я тоже нигде не говорил за реализацию бизнес-логики в слое презентации. Эта коммуникационная прослойка - это и есть вьюмодель. И именно эта прослойка отделяет вью от модели. Теперь у вас ваша вью отвечает не только за то, как данные выглядят на экране, но и за то, чтобы их запросить, форматировать и прочее.
Все правильно - это изменение вьюмодели без изменения вью. Ваше вью - это страница с кнопкой Выйти. Она останеться такой же, как и до этого. В приведенном выше условном примере используется менеджер диалогов. Он не будет частью непосредсвенно вашей страницы. Это отдельная сущность, которая отвечает за разного рода диалоги.
Отделение бизнес-логики от вью - это не разнесение всего этого по разным классам. Отделение, в данном случае - это когда V и М не связаны напрямую. Именно такой вот непрямой связкой и занимается вьюмодель. Если вы объедините вью и вбюмодель в один класс, то у вас вью будет отвечать за коммуникацию с моделью.
В данном случае, я не спорю с вами о главном выводе, просто потому, что я не достаточно хорошо знаю Flutter. Возможно каки-то особенности именно этого фреймворка приводят к тому, что MVVM не подходит. Но откровенно говоря, приведенные вами примеры этого не описывают.
Мне кажется. что вы основываете свои выводы на утверждении, что VM - это просто UI-логика. А это не так. Наличие UI-логики во вьюмодели, не означает, что там нет логики по коммуникации с моделью (что приводит нас к выводу, что это не исключительно UI-логика).
Нет, к разделению бизнес-логики и интерфейса ViewModel не имеет никакого отношения. Бизнес-логикой в MVVM вообще занимается слой M. ViewModel – это отделение UI-логики от UI.
Вообще-то имеет. Именно VM обеспечивает непрямое взяимодействие V и M, обезпечивая loose coupling.
The viewmodel of MVVM is a value converter,[1] meaning the viewmodel is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented.
The view model is also responsible for coordinating the view's interactions with any model classes that are required.... Each view model provides data from a model in a form that the view can easily consume.
Есть Xamarin.iOS и Xamarin.Android (aka Xamarin.Native) - там UI пишут свой под каждую платформу, бизнес-логика расшарена. Xamarin.Forms - UI тоже расшарен (или большая его часть). Потому и разница.
В разработке уже есть устоявшаяся аббревиатура DDD - это domain-driven design. Мне кажется, что использовать ее для какой-то другой концепции разработки неправильно.
Как я понимаю, в исследовании это учитывается (страница 5 статьи)
Determining the concentration of ownership is more complicated than just tracking the holdings of the richest addresses, since many of the largest addresses belong to cold wallets of exchanges and online wallets, which hold Bitcoin on behalf of many investors. We develop a suite of algorithms based on graph analysis to classify addresses into those belonging to individual investors or those belonging to intermediaries.
Если честно, то у меня сложилось мнение, что у вас какое-то особое представление о MVVM. Возможно, что в нативном Android, он действительно имплементрован как-то по-особенному (а вы ссылаетесь именно на Android). Я вам советую почитать о нем на сайте Microsoft.
Да потому что как вам выше уже писали, диалоги управляются менеджером диалогов. Просто вам такой подход не понравился, и вы искренне считаете, что созданием и отресовкой диалога должна заниматся именно та страница, на которой он вызван.
Не совсем точно такая же. На мобильных устройствах диалоги, чаще всего (хотя теоретически не обязательно), перекрывают весь экран и блокируют страницу. При этом, вы (как правило) видите только один диалог. Бывают ситуации, когда диалоговое окно надо показать на уровне вашего приложения (может прилетела ошибка из другой части программы). Но показывать два диалога одновременно - будет странно. Значит вам все равно надо что-то, что управляет ими всеми. И тогда вы тащите новые зависимости в ваше вью. Можно это делать? Технически - конечно. Но тогда ваше вью все разростается и разростается.
Но диалоги - это лишь частный пример. Вам просто не нравится идея, что если какая-то логика принадлежит UI, то она может быть где-то еще. Лично я не вижу в этом никаких проблем, так как есть четкая структура. Нет никакой сложности в понимании, где находить в вашем коде именно структуру UI, а где его логика. Добавляет ли это код - да... несколько строк в отдельном файле, и все.
Между прочим, у вас вообще нигде не сказано за binding. А между прочим - это одна из ключевых характеристик паттерна. Еще раз советую побольше о нем почитать.
Если вы искренне уверены, что предложенная вами архитектура более рациональна, возможно лучше представлять ее публике в чистом виде, а не под соусом, что MVVM - антипаттерн. Я бы также подумал над лучшими примерами. Предложенные в статье лично меня не переубеждают.
Диалог - это часть UI, полноправная. Но мы же тут не говорим об изменении любого UI в вашем приложении. Мы говорим об изменении конкретной страницы. А в этом случае она останется такой же.
А зачем вашей вью (именно экрану, где располагается кнопка выхода), знать о наличии этого диалога (это и есть, кстати, пример tight coupling)? В данном конкретном случае, нажатие на кнопку Выйти просто запускает процесс выхода. А как вы структурируете этот процесс - это другое дело. Представьте, что этот процесс состоит из нескольких стадий, или с разными опциями, возможно он требует дополнительной бизнес-логики, и все эти стадии и опции никак не влияют на тот экран с кнопкой выйти.
Собсвенно я тоже нигде не говорил за реализацию бизнес-логики в слое презентации. Эта коммуникационная прослойка - это и есть вьюмодель. И именно эта прослойка отделяет вью от модели. Теперь у вас ваша вью отвечает не только за то, как данные выглядят на экране, но и за то, чтобы их запросить, форматировать и прочее.
Все правильно - это изменение вьюмодели без изменения вью. Ваше вью - это страница с кнопкой Выйти. Она останеться такой же, как и до этого. В приведенном выше условном примере используется менеджер диалогов. Он не будет частью непосредсвенно вашей страницы. Это отдельная сущность, которая отвечает за разного рода диалоги.
Вот что нам говорит оффсайт.
https://bloclibrary.dev/#/architecture?id=business-logic-layer
Think of the business logic layer as the bridge between the user interface (presentation layer) and the data layer.
Весьма близко к функциям вьюмодели.
Отделение бизнес-логики от вью - это не разнесение всего этого по разным классам. Отделение, в данном случае - это когда V и М не связаны напрямую. Именно такой вот непрямой связкой и занимается вьюмодель. Если вы объедините вью и вбюмодель в один класс, то у вас вью будет отвечать за коммуникацию с моделью.
В данном случае, я не спорю с вами о главном выводе, просто потому, что я не достаточно хорошо знаю Flutter. Возможно каки-то особенности именно этого фреймворка приводят к тому, что MVVM не подходит. Но откровенно говоря, приведенные вами примеры этого не описывают.
Мне кажется. что вы основываете свои выводы на утверждении, что VM - это просто UI-логика. А это не так. Наличие UI-логики во вьюмодели, не означает, что там нет логики по коммуникации с моделью (что приводит нас к выводу, что это не исключительно UI-логика).
Вообще-то имеет. Именно VM обеспечивает непрямое взяимодействие V и M, обезпечивая loose coupling.
https://en.wikipedia.org/wiki/Model–view–viewmodel
The viewmodel of MVVM is a value converter,[1] meaning the viewmodel is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented.
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm#viewmodel
The view model is also responsible for coordinating the view's interactions with any model classes that are required.... Each view model provides data from a model in a form that the view can easily consume.
Есть Xamarin.iOS и Xamarin.Android (aka Xamarin.Native) - там UI пишут свой под каждую платформу, бизнес-логика расшарена. Xamarin.Forms - UI тоже расшарен (или большая его часть). Потому и разница.
В разработке уже есть устоявшаяся аббревиатура DDD - это domain-driven design. Мне кажется, что использовать ее для какой-то другой концепции разработки неправильно.
Уже все вернули обратно. https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/ https://github.com/dotnet/sdk/pull/22262