Как ввести сам ninject в статический класс с дополнительными функциями

Question

Как ввести сам ninject в статический класс с дополнительными функциями

Я получил некоторые статические классы с дополнительными методами, которые добавляют 'бизнес-логику' к объектам с помощью шаблона репозитория.

Теперь иногда я должен создать новое IRepository в этих дополнительных функциях.

Я в настоящее время работаю вокруг этого путем доступа к моему ядру Ninject через объект, который я расширяю, но это действительно ужасно:

public static IEnumerable<ISomething> GetSomethings(this IEntity entity)
{
    using (var dataContext = entity.kernel.Get<IDataContext>())
        return dataContext.Repository<ISomething>().ToList();
}

Я мог также сделать статического конструктора, получив доступ к ядру Ninject так или иначе от фабрики, уже там инфраструктура для этого в Ninject 2?

Кто-либо знает лучшее решение? Делает у кого-либо есть некоторые комментарии к этому способу реализовать бизнес-логику.

5

c# extension-methods repository-pattern ninject ninject-2

задан Ruben Bartelink 14 May 2010 в 14:10

1 ответ

Другие вопросы по тегам:

c# extension-methods repository-pattern ninject ninject-2

Похожие вопросы:

score 4 · Accepted Answer

По вопросу о методах расширения и способах их получения. У вас есть два подхода:

Местоположение службы - глобальное ядро и раскрывающееся меню «Местоположение службы» (которое отличается от внедрения зависимостей). Проблема здесь в том, что ваша сущность (или ее расширения) не должны принимать свой контекст и вместо этого требовать его
Поскольку вы являетесь методом расширения, то, что вы расширяете, передайте вам то, что вам нужно

Как вы ' Мы более или менее догадались, что Ninject пытается отговорить вас от этого (наличие глобального ядра, которое становится свалкой). В общем, расширение для всего, что вы используете (например, MVC или WCF), предоставит что-то, если это уместно. Например, расширение WCF имеет http://github.com/ninject/ninject.extensions.wcf/blob/master/source/Ninject.Extensions.Wcf/NinjectServiceHost.cs

Более серьезная проблема здесь в том, что Подобные зависимости, вероятно, не должны распространяться вниз до уровня Entity - они должны оставаться на уровне Service и распространяться оттуда (с использованием словаря DDD).

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