0

Мне надо регистрировать типы (использую Autofac). Стоит ли нагружать класс App в WPF непосредственно регистрацией типов внутри метода OnSturtup (объявлять IContainer, ContainerBuilder итд) или стоит сделать отдельные классы которые будут только регистрировать типы, а затем уже вызывать методы регистрации внутри OnSturtup?

Сейчас надо регистрировать 3 типа, однако это только начало.

По идее класс App нужен для определения общих ресурсов для приложения и поэтому можно регистрировать прямо сразу в классе, но тогда класс App будет засорен существованием IContainer и прочих сущностей. Не лучше ли вынести это в отдельные классы? А может стоит регистрировать типы вообще где-то в другом месте?

Правда не знаю в каком. Помогите определиться с тем "как правильно"

Aarnihauta
  • 2,326
  • 3
  • 12
  • 23
  • Пишите пока всё в OnStartup(). Когда вы доберетесь хотя-бы до 100 типов, вы точно будете знать, надо уносить код или нет. Отрефакторить Composition Root в отдельный класс - дело нескольких секунд, независимо от размера кода. – aepot Dec 15 '21 at 09:11
  • Лично мне нравится подход как в asp.net core, где все разнесено по сборкам и классам вида ServiceContainerExtensions с методами расширениями вида AddFeature(this IServiceCollection...), где и происходит регистрация нужного функционала. И в OnStartup() подключать это как services.AddFeature1(); services.AddFeature2(). И даже в основном ехе такой же класс делать. Читабельно, структурировано, расширяемо. – vitidev Dec 15 '21 at 13:45
  • @vitidev когда столкнулся с проблемой сразу подумал о таком же подходе как в asp core, но чего-то сложно мне оно всё показалось так как я не особо хорошо знаком с asp – Aarnihauta Dec 15 '21 at 13:47
  • asp тут никаким боком. Портянку регистраций и так придется распихивать по методам, чтобы ориентироваться как-то. Разница лишь в том - как передать контейнер в этот метод. Ну и где этот метод будет. Метод регистрации фичи будет в той сборке, где сама фича - ведь только там можно увидеть internal. Ну а передача контейнера как this делает список подключения чище. services.AddFeature1();, а не ExtModuleRegistration.AddFeature1(container) – vitidev Dec 15 '21 at 13:57
  • Я вам советую вообще такой подход. – EvgeniyZ Dec 15 '21 at 14:06
  • Даже если у вас одна сборка, то и там вы можете запихать эти методы в 1 класс, а можете положить рядом с фичами (которые по папкам разложены) для структурности (весь код фичи должен быть рядом, а не размазан по проекту). Нужно будет - всю эту папку выделим в отдельную сборку. Навигация легкая - прыгаем в OnStarup и дальше в нужное место – vitidev Dec 15 '21 at 14:08

1 Answers1

1

На мой взгляд, ваш случай хорошо разобран в prism(autofac/unity). Один из авторов сего фреймворка - Brian Lagunas(Microsoft MVP, Xamarin MVP, Microsoft P&P Champion etc). Человек явно что-то понимает в архитектуре приложений, если, по крайне мере, раньше этот фреймворк часто использовали в корпоративных приложениях.

Ниже пример #20

В библиотеке объявляем свой инициализатор:

public class ModuleAModule : IModule
{
    public void OnInitialized(IContainerProvider containerProvider)
    {

}

public void RegisterTypes(IContainerRegistry containerRegistry)
{
    //Что-то регистрируем
}



}

В самом приложении добавляем наши библиотеки-модули:

public partial class App : PrismApplication
{
    protected override Window CreateShell()
    {
        return Container.Resolve<MainWindow>();
    }

protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
    //Здесь регистрируем локальные сервисы

}

protected override void ConfigureModuleCatalog(IModuleCatalog moduleCatalog)
{
    //Наш модуль
    moduleCatalog.AddModule&lt;ModuleA.ModuleAModule&gt;();
}



}

Примеры(29шт)

PrismApp

IModule

Lapish
  • 580
  • 3
  • 12