Я использую Ninject. На моем проекте:
- Объекты сервисного уровня внедряются в контроллеры (с помощью конструктора).
- Хранилища внедряются в объекты сервисного уровня (с помощью конструктора).
- ObjectContext внедряется в репозитории (с помощью конструктора).
- Параметр web.config инкапсулирован в класс, который реализует интерфейс IAppSettings, который затем внедряется в сервисный уровень.
- NinjectActionInvoker вводится как IActionInvoker. Он заботится о внедрении сервисов в ActionFilters.
- У меня есть собственная реализация интерфейса
IPrincipal
, который внедряется в уровень обслуживания вместо ссылки на HttpContext.Current.User
.
Пример использования Ninject:
public class UserService : GenericService<User>, IUserService
{
public ISettingService SettingService { get; set; }
public ICTEmailSender CTEmailSender { get; set; }
public ICTSettings CTSettings { get; set; }
public ICTPrincipal User { get; set; }
}
Ninject rules:
Bind<ICTPrincipal>().ToMethod(c => (ICTPrincipal)HttpContext.Current.User).OnlyIf(a => HttpContext.Current.User is ICTPrincipal);
Bind<ICTEmailSender>().To<CTEmailSender>();
Bind<ICTSettings>().To<CTSettings>();
В контроллер вводится не только служба, но и части службы. Это делает сервис более тестируемым. Я уверен, что это может быть легко перенесено в замок.