Точка входа в DLL

Question

У меня есть приложение c# .net WPF, теперь мне нужно зарегистрировать что-то (в основном ядро ​​шаблона NInject IoC), которое использовалось слоями BLL и DAL.

Я хочу знать точку входа или что-то подобное для dll, где я мог бы поместить этот код (регистрация ядра).

Для секции WPF я использую App.xaml.cs, для секции WCF я использую Global.asax.cs, поскольку они являются точкой входа в эти вещи. Но как насчет автономных dlls, какова их точка входа.

Один из подходов состоит в том, что я могу добавить статический класс в мою dll, который выполняет эту задачу, и с app.xaml.cs я вызываю этот метод BLL и регистрирую мои ядра. Но это больше похоже на обходной путь, чем на подход.

Пожалуйста, ведите меня к чему-то более конкретному и логичному.

Answer 1

Конфигурация контейнера выполняется в составном корне вашего приложения (точка, в которой ваш код вызывается в первый раз).Как вы уже сказали, в случае WPF это App.xaml.cs.Здесь вы регистрируете компоненты ВСЕХ слоев.Желательно, чтобы у вас был код пользовательского интерфейса в другой сборке, чем App.xaml.Таким образом, создание приложения полностью отделено от выполнения кода.

Предлагаю прочитать книгу Марка Симанса, где это подробно описано.

Answer 2

C # не позволяет запускать код при загрузке сборки, а конструкторы статического класса лениво выполняются при первом доступе к классу. Однако CLR поддерживает, так сказать, статический «конструктор сборки», который выполняется при первой загрузке сборки. Напоминаем, что ссылки по-прежнему загружаются лениво, если вы не добавите специальные атрибуты, чтобы пометить ссылочную сборку для быстрой загрузки.

Если хотите, вы можете поместить статический конструктор в модуль сборки через ildasm / ilasm. Возможно, вы могли бы сделать несколько сценариев для автоматизации этого при сборке.

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

Answer 3

Это звучит почти так, как если бы вы хотели модель «плагин», где приложение может динамически обнаруживать доступные компоненты. Если это так, то MEF может быть лучшим вариантом.

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

Я не знаю, за этим ли вы следите, но, возможно, стоит посмотреть.