По сути вам уже дали ответ на ваши вопросы, я лишь этим ответом хочу показать то, как можно поступить, некий подход проектирования, который имеет мало связанные друг с другом объекты, использует сервисы и DI контейнер.
И так, MVVM, это когда все разделено на мало связанные друг с другом слои, где
- Model - это слой с вашими данными. Конкретно в вашем случае
BleController, это Model.
- ViewModel - слой, который общается с Model и предоставляет для UI необходимые публичные свойства для привязки.
- View - слой с нашим UI, то есть вся XAML разметка и все то, что видит пользователь.
То есть, все наше приложение становится максимально удобно для внедрения чего-либо нового или изменения старого, а если все это еще и завязывать на абстракции, то мы вовсе можем сделать проект, который состоит из кучи маленьких.
Что такое сервис: Создавать объекты самостоятельно, это порой муторно и зачастую портит ту самую "слабую связь" между объектами, ведь мы явно указываем = new SomeClass();. Небольшой пример:
ILogger
{
void Send(string msg);
}
class FileLogger : ILogger
{
public void Send(string msg)
{
// Записываем в файл наш лог.
}
}
class SomeClass
{
ILogger logger = new FileLogger(); // new ServerLogger() // new ConsoleLogger() ...
void Method() => logger.Send("Данные в лог");
}
Предположим, что SomeClass, это некий класс, который находится у нас в библиотеке, ну и тут сразу думаю становится очевидно то, что он имеет зависимость от класса Logger и от интерфейса ILogger, что не есть хорошо. Ок, перепишем его следующим образом:
class SomeClass
{
ILogger logger;
public SomeClass(ILogger logger)
=> this.logger = logger;
public void Method() => logger.Send("Данные в лог");
}
Мы с вами сделали Dependency Injection (DI), то есть внедрили зависимость в наш класс за его пределами, что позволяет теперь ему существовать только ссылаясь на интерфейс.
Имея это, мы можем теперь полностью убрать из нашего проекта все = new ... ();, как? Да все просто, при помощи контейнеров.
Контейнер - это некая реализация, которая в себе хранит зарегистрированные типы и объекты и в случае необходимости, отдает их при помощи DI или прямого запроса. Если очень грубо объяснять, то контейнер, это словарь объектов/типов, который обычно только раз настраивается и больше про него не вспоминают. Давайте приведу простой псевдокод:
Предположим, что у нас есть те классы, что выше и есть контейнер, в который мы добавляем эти зависимости:
class Program
{
ILogger logger;
SomeClass someClass;
public Program(ILogger logger, SomeClass someClass)
=> (this.logger, this.someClass) = (logger, someClass);
public void SomeLogic()
{
var result = "Некие данные";
someClass.Method();
logger.Send(result); // логируем их.
}
}
var container = new SomeContainer();
container.Register<SomeClass>();
container.Register<ILogger, Logger>();
container.Register<Program>();
var program = container.Resolve<Program>();
program.SomeLogic();
Здесь мы зарегистрировали нужные нам типы в контейнере и дальше попросили из него лишь один объект (Program), в который он сам внедрил все необходимые зависимости, нам не нужно хардкодить = new Logger(); .. = new SomeClass(logger);, нет, это все сделает за нас контейнер, добавляй только нужные типы, да и все.
Но ок, как это все связано с сервисами? Честно, могу ошибаться, но понятие "сервис" пошло от ASP.NET, где весь проект и строится на DI и контейнере, а все зависимости, которые регистрируются в контейнере и называются "сервис". То есть, сервис, это некий класс, который имеет нужную нам логику, допустим, работа с базой, ну и сам этот сервис лежит в контейнере.
Ничего не понятно, можно пример?
Знаете, в WPF и Xamarin проектах, всю эту схему очень классно раскрывает один весьма популярный пакет, зовется Prism. С вашего позволения, я сделаю WPF проект на его основе, а там вам не составит труда подставить свои компоненты и адаптировать все под Xamarin.
Создаем новый проект (у меня WPF).
Устанавливаем из NuGet один из DI контейнеров под Prism, я возьму Prism.DryIoc, он также подтянет Prism.Wpf, DryIoc.dll и ряд других зависимостей.
Создаем две папки Views и ViewModels.
Переносим MainWindow в Views, попутно поправляя в ней все namespace.
Переписываем стартовую точку проекта:
Открываем App.xaml и добавляем туда пространство имен xmlns:prism="http://prismlibrary.com/"
Удаляем StartupUri
Меняем <Application на <prism:PrismApplication
Открываем App.xaml.cs и убираем там наследование от : Application
Реализуем все необходимое, следуя подсказкам студии. У нас будет два переписанных метода:
CreateShell() - он отвечает за создание основного окна нашего проекта, некий аналог StartupUri из App.xaml, только окно берется из контейнера, со всеми зависимостями. Нам достаточно просто написать в нем return Container.Resolve<MainWindow>();
RegisterTypes(IContainerRegistry containerRegistry) - метод, в котором мы регистрируем все необходимые нам типы для контейнера.
В итоге получим нечто такое:
public partial class App
{
protected override Window CreateShell()
=> Container.Resolve<MainWindow>();
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
// Регистрируем сервисы и другие типы.
}
}
В классе окна прописываем xmlns:prism="http://prismlibrary.com/" и prism:ViewModelLocator.AutoWireViewModel="True". Эта позволит автоматически находить ViewModel для окна.
Сделаем вывод текста, простой TextBlock по центру окна и привязанный к свойству Text
<TextBlock Text="{Binding Text}" VerticalAlignment="Center" HorizontalAlignment="Center" FontSize="30"/>
В папке ViewModels сделаем класс *ViewModel, где * это название наше View. То есть делаем MainWindowViewModel. Если View зовется SomeView, то VM должна называться SomeViewModel, а не SomeViewViewModel!.
В созданном VM классе делаем то самое свойство, которое мы привязали:
public string Text { get; set; } = "Привет мир!";
В итоге на данном этапе наш проект выглядит так:
Можем уже запускать
Я думаю, вы уже заметили, что в архитектуре нашего проекта нету каких-либо = new .. (), все мало связанно друг с другом и работа идет через контейнер зависимостей. Теперь давайте добавим еще больше магии...
Добавим в наше решение новый проект, библиотеку классов, назовем [названиеПроекта].Services.Interfaces, чтоб не запутаться и поместим его в директорию Services. Этот проект пусть отвечает только за интерфейсы.
Создадим в этом проекте интерфейс, не будем отходить от "традиций", пусть будет, как и ранее ILogger, некий интерфейс, который отвечает за логирование проекта.
public interface ILogger
{
event Action<string> OnNewLog;
void Send(string message);
}
Для наглядности, сделаем еще один интерфейс, просто чтобы вы поняли суть, назовем его ITime, пусть отвечает за получение времени:
public interface ITime
{
DateTime GetTime();
}
Создадим еще один проект, также в директории Service и назовем его LoggerService, добавим ему в зависимости ранее созданный проект интерфейсов, а в нем класс, который будет реализовывать интерфейс ILogger, к примеру так:
public class FileLoggerService : ILogger
{
public event Action<string> OnNewLog;
public ITime time;
public FileLoggerService(ITime time)
=> this.time = time;
public void Send(string message)
{
// Делаем нечто с сообщением.
OnNewLog?.Invoke($"[{time.GetTime().ToShortTimeString()}] {message}");
}
}
Заметьте, мы не знаем чего-либо про реализацию ITime, мы даже не можем написать time = new ...(), ибо попросту нету этого класса, мы знаем только то, что есть некий интерфейс, не более. Это отлично показывает то, как слабо связаны друг с другом слои и проекты в целом, ведь реализация ITime может быть где угодно, хоть также, в отдельном проекте.
К основному проекту подключаем SOProject.Services.Interfaces и SOProject.Services.LoggerService.
Делаем реализацию ITIme:
public class TimeNow : ITime
{
public DateTime GetTime()
=> DateTime.Now;
}
Регистрируем в контейнер все типы:
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
// Регистрируем сервисы и другие типы.
containerRegistry.Register<ILogger, FileLoggerService>();
containerRegistry.Register<ITime, TimeNow>();
}
Переписываем MainWindowViewModel:
public class MainWindowViewModel
{
private ILogger logger;
public MainWindowViewModel(ILogger logger)
{
this.logger = logger;
SendLogCommand = new DelegateCommand<string>(log => logger.Send(log));
this.logger.OnNewLog += log => Logs.Add(log);
}
public ObservableCollection<string> Logs { get; } = new();
public ICommand SendLogCommand { get; }
}
Тут все просто, мы получаем логгер через DI, а также делаем коллекцию, куда будем писать сообщения и команду, которая будет отправлять в логгер сообщение, а также мы подписываемся на событие, которое добавит нам в коллекцию сообщение.
Осталось реализовать View:
<Grid>
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition Height="Auto"/>
</Grid.RowDefinitions>
<ListBox ItemsSource="{Binding Logs}"/>
<Grid Grid.Row="1">
<Grid.ColumnDefinitions>
<ColumnDefinition/>
<ColumnDefinition/>
</Grid.ColumnDefinitions>
<TextBox Grid.Column="0" x:Name="logText"/>
<Button Grid.Column="1"
Command="{Binding SendLogCommand}"
CommandParameter="{Binding Text, ElementName=logText}"
Content="Отправить"/>
</Grid>
</Grid>
Запускаем, смотрим
Заметьте, это все идет через наш сервис, который мы получили через все тот же интерфейс. Сам проект в итоге выглядит так:
Вот вам и реализация проекта по правилам MVVM, с DI контейнерами, ну и с сервисами, где все мало связано друг с другом, что дает максимальные возможности для тестирования и дальнейшего развития, ведь если нам нужна будет новая логика, мы ее можем сделать также в новой DLL, которую потом достаточно будет зарегистрировать в контейнере и использовать там, где нам надо.
Prism я тут взял как хорошего помощника, который позволяет очень многое, хоть делайте модули, которые будут автоматически подключаться в проект, находясь с ним в одной директории, хоть делите View на слои. Но тут должны сами понимать, все зависит от проекта и ваших желаний, вы можете вовсе все это делать в одном проекте и использовать чисто MVVM подход, вам не запрещают. Главное, поймите суть этого всего и знайте, что такая возможность существует.
