МСУSeVaМуслими, это ты кроме своего говнокода ничего не видел, а посему завышенная самооценка и ноль знаний.
Это слова истерички, которая генерирует сборку прямо в памяти, которая говорит, что IPrincipal круче мембершипа? Я плакал.
SeVaЕсли посмотреть код DependencyResolver, который ты по своей обычной безграмотности обозвал контейнером, а потом с ослиным упорством пачка мозги на пяти страницах, то сразу всем будет понятно, что ты ишак
Если посмотреть возможности DependencyResolver, то обнаружишь своим тупорылым мозгом еще дополнительные возможности, которым не обладает локатор. Отсюда можно сделать вывод, что ты кретин.
SeVaНормальный фреймворк должен не зависеть от контейнеров и достигается это с помощью servicelocator.
Бестолочь, нормальный фреймворк предоставляет возможность определять зависимости прямо не отходя от кассы. Как это сделано в MVC.
SeVaВ mvc можно зарегистрировать внешний или использовать две готовые реализации с куцыми возможностями, которые по своим возможностям и близко не стояли рядом с нормальными ioc контейнерами.
Ты упоротая обезьяна. В MVC DependencyResolver может регистрировать любой сторонний DI, в том числе и Unity
http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
public class UnityDependencyResolver : IDependencyResolver
{
private IUnityContainer container;
private IDependencyResolver resolver;
public UnityDependencyResolver(IUnityContainer container, IDependencyResolver resolver)
{
this.container = container;
this.resolver = resolver;
}
public object GetService(Type serviceType)
{
try
{
return this.container.Resolve(serviceType);
}
catch
{
return this.resolver.GetService(serviceType);
}
}
public IEnumerable<object> GetServices(Type serviceType)
{
try
{
return this.container.ResolveAll(serviceType);
}
catch
{
return this.resolver.GetServices(serviceType);
}
}
}
SeVaПосему можно делать однозначный вывод: ты не знаешь mvc и никогда не нюхал контейнеры, одна только вонь на форумах с говносервисами.
Ты как был бездарностью, так ей и остался.
И какие же это дополнительные возможности, чмо?
Единственное, чем отличается DependencyResolver от ServiceLocator'а - это обработка ситуации, когда невозможно создать объект. Первый возращает null, а второй exception.
А так, что называется, найдите отличия
Совершенно одинаковые интерфейсы.
Реализации для unity практически не отличаются.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
using System;
using System.Collections.Generic;
using Microsoft.Practices.ServiceLocation;
namespace Microsoft.Practices.Unity.ServiceLocatorAdapter
{
public class UnityServiceLocator : ServiceLocatorImplBase
{
private IUnityContainer container;
public UnityServiceLocator(IUnityContainer container)
{
this.container = container;
}
/// <summary>
/// When implemented by inheriting classes, this method will do the actual work of resolving
/// the requested service instance.
/// </summary>
/// <param name="serviceType">Type of instance requested.</param>
/// <param name="key">Name of registered service you want. May be null.</param>
/// <returns>
/// The requested service instance.
/// </returns>
protected override object DoGetInstance(Type serviceType, string key)
{
return container.Resolve(serviceType, key);
}
/// <summary>
/// When implemented by inheriting classes, this method will do the actual work of
/// resolving all the requested service instances.
/// </summary>
/// <param name="serviceType">Type of service requested.</param>
/// <returns>
/// Sequence of service instance objects.
/// </returns>
protected override IEnumerable<object> DoGetAllInstances(Type serviceType)
{
return container.ResolveAll(serviceType);
}
}
}
Что еще нужно, чтобы до тебя дошло, что ты тупорылое чмо, которое ничего не знает?
