Комментарии 5
Более традиционен подход в котором объекты view model взаимодействуют с функционалом предметной области не напрямую, а через тонкий слой объектов application logic. Это можно объяснить тем что объектам view model совершенно не обязательно знать о деталях реализации бизнес-логики, а достаточно знать о том какой объект и метод application logic надо вызвать в каждом конкретном случае.
По правде говоря, я действительно рассматривал такой вариант, но на тот момент мне показалось, что в таком случае проект может оказаться сильно перегруженным абстракциями.
В своем приложении у меня получилось, что роль Application logic выполняют как раз сами ViewModels, что не совсем правильно с точки зрения архитектуры, наверное, но прикладной логики оказалось не так много, так что выделять под эти задачи отдельные сервисы я не стал.
Почему не стали в проекте использовать CommunityToolkit? позволяет сократить объем самописного кода расширением классов ViewModel через partial class, добавлять такие фишки как ObservableValidator для валидации свойств ViewModel и RelayCommand для обработки событий. Как раз в настоящее время изучаю MAUI и пишу свой проект. Опыта какой-либо разработки нет, есть желание учиться.
На самом деле, CommunityToolkit как пакет у меня установлен в приложение, но сделал я это ровно для одного - изменение цвета PNG-изображений, что не очень хорошо, конечно.
Я изначально создавал это приложение для цели "попробовать" MAUI как таковой. По этой же причине я не стал использовать Blazor, например. Также, с разработкой приложений на .NET я был мало связан, поэтому хотелось лучше понять логику построения программы, модель взаимодействия между объектами, чтобы лучше понять какие конкретно проблемы будут решаться сторонними пакетами, чтобы взвесить все "за" и "против" его установки.
Совместить DDD и MVVM: Разработка приложения-трекера расходов по правилу 50-30-20 на .NET MAUI