Skip to main content

Ioc - Autofac

Related posts:

Astăzi a venit rîndul la Autofac (http://code.google.com/p/autofac/) sa fie prezentat.
Clasa care se ocupa de container se numește ContainerBuilder. Folosind aceasta clasa putem sa înregistram sau sa rezolvam orice componenta. La fel ca si Ninject, paternul folosit pentru setup-ul containerului este fluent. Mai jos puteți sa găsiți un exemplu care arata cum se poate înregistra un element în container.
ContainerBuilder containerBuilder = new ContainerBuilder();

containerBuilder
.RegisterType<OderService>()
.As<IOrderService>();
Trebuie sa aveti grija ca intai se specifica clasa care implementează tipul pe care dorim sa îl mapam și doar apoi interfata (sau clasa care vrem sa o mapam). Autofac este destul de deștept ca sa poată detecta cu ce obiect vrem sa mapam un anumit tip. Este de ajuns sa specificam doar OrderService:
containerBuilder

.RegisterType<OderService>();
Constructorul care se va folosii este cel care are cei mai multi parametrii care pot sa fie rezolvati din container. In cazul in care dorim sa specificam parametrii la constructori, atunci trebuie sa scriem urmatorul cod:
containerBuilder

.RegisterType<ComputeService>()
.WithParameters(
new NamedParameter(state, 1));
Pentru a putea obține un element din container este nevoie sa folosim metoda Resolve. Aceasta metoda acepta si lista de parametri cu care dorim sa initializam obiectul.
IOrderService orderService = containerBuilder.Resolve<IOrderService>();

Problema propietatiilor si a constructoriilor complexi a fost destul de simplu rezolvata prin metoda Regiser, care accepta o expresie lambda. Prin intermediul acestei expresii putem as configuram obiectul nostru în orice fel.
containerBuilder

.Register(cs => new ComputeService(1){ MaximProcessor = 10; });
Folosind o expresie lambda putem sa injectam orice valoare, atata timp cat propietatiile sunt publice. Cand lucram cu tipuri generice pe care dorim sa le mapam putem sa folosim metoda RegisterGeneric, dar nu este obligatoriu. Daca dorim sa mapam mai multe obiecte pentru aceiasi interfate, este bine de stiut ca ultimul obiect inregistrat o sa fie considerat cel default. Pentru a pastra ca obiect default, obiectul deja mapat, este nevoie sa folosim metoda PreserverExistingDefaults().
containerBuilder

.RegisterType<ComputeService>()
.As<IComputerService>()
.PreserveExistingDefaults();
Pentru fiecare obiect inregistrat putem sa alocam nu doar un nume ci si o cheie. De exemplu putem sa folosim un enum, a.i. nu o sa fim obligati sa folosim string-uri pentru a rezolva un anumit obiect.
// pe baza de nume

containerBuilder
.Register<ComputeService>()
.Named<IComputerService>("computeServiceOne");
containerBuilder.ResolveNamed<IComputeService>("computeServiceOne");
// pe baza de cheie. Presupunem ca avem urmatorul enum: enum ComputerServiceTypes { Manual, Auto }
containerBuilder
.RegisterType<ComputeService>()
.Keyed<IComputeService>(ComputerServiceTypes.Auto);
containerBuilder.ResolveKeyed(ComputerServiceTypes.Auto);

Un lucru în plus care il aduce Autofac și se poate folosii cu succes în aplicațiile care inițial nu au avut un container IoC, este ExternallyOwned. In cazul în care folosim paternul Singleton, putem sa mapam o proprietate statica pentru a fi procesata de către container.
containerBuilder

.RegisterInstance(ComputeService.Instance)
.ExternallOwned();
La Resolver putem sa specificam valori la parametrii (pe baza de nume, tip). Mai jos puteti sa gasiti un exemplu.
containerBuilder.Resolve<IComputeService>(new NamedParameter("MaximProcessor",10));

In momentul în care setam valori la proprietate putem sa avem cazuri cînd apar dependinte circulare. Autofac știe sa lucreze cu ele, doar ca este nevoie sa ne folosim de metoda OnActivated pentru a specifica propietare care provoaca o dependinta circulara (mare parte din framework-uri nu suporta dependintele circulare).
containerBuilder

.Register(c => new ComputeService())
.OnActivated(c => c.PropDeTipComputeService = c.Context.Resolve<IComputeService);
Exista 3 evenimente la care ne putem atasa pentru a executa cod custom:
  • OnActivating
  • OnActivated
  • OnRelease
Acestea pot sa fie folosite de exemplu cînd vrem sa injectam o metoda într-un anumit moment.
containerBuilder

.Register(c => new ComputeService())
.OnActivating( e => some code);
In cazul in care dorim sa mapam toate interfețele dintr-un assembly avem la dispozitie RegisterAssemblyTypes. Prin intermediul acestei metode putem sa mapam automat orice clase dintr-un anumit assembly.
containerBuilder

.RegisterAssemblyTypes(Assembly.GetExecuteAssembly())
.Where(type => type.Name.EndWith("Service")) // conditie
Autofac ne permite sa controlam durata de viata a unui obiect asemanator cu Ninject, doar cu mici diferente.
  • Transient (o instanta noua de obiect la feicare call) este denumita PerDependency - InstancePerDependency();
  • Singleton (o instanta unica per aplicatie) - SingleInstance();
  • LifetimeScope (o instanta unica per request) - InstancePerLifetimeScope();
  • Contextual (asemanatoare cu LifetimeScope) doar ca controlul duratei de viata a obiectului se poate controla din cod - InstancePerMatchingLifetimeScope;
Avem la dispoziție interfața IStartable, care ne permite sa rulam un cod custom în momentul în care containerul este creat. Pentru a face acest lucru trebuie sa implementam interfața data și sa o înregistram in container.
class StartupCode : IStartable

{
public void Start()
{
// Cod custom care o sa fie rulat in momentul i ncare containerul este initializat.;
}
}
containerBuilder
.RegisterType<StarupCode>()
.As<IStartable>()
.SingleInstance(); // O singura instanta per container.
In cazul în care vrem sa înregistram mai multe obiecte, le putem grupa pe module. Fiecare modul trebuie sa implementeze clasa Module și sa face ovveride la metoda Load. In aceasta metoda trebuie sa inregistram obiectele dorite.
public class ComputeModule : Module

{
protected override void Load(ContainerBuilder containerBuilder)
{
containerBuilder
.RegisterType<OderService>()
.As<IOrderService>();
containerBuilder
.Register(c => new ComputeService());
}
}

Toate aceste configurări pot sa fie făcute și printr-un fișier de configurare. Fiecare componenta pe care dorim sa o înregistram este nevoie sa o mapam într-un nod de tip component. Nu vreau sa intru in detaliu, deoarece sunt exact aceleași configurări care se pot face si din cod. Ce merita menționat aici este faptul ca dacă ne definim module, le putem configura (seta proprietatiile) din fișierul de configurare.
Autofac se poate integra foarte ușor cu ASP.NET, ASP.NET MVC, MEF (Managed Extensibility Framework), WCF, NServiceBus, Moq, NMock si NHibernate.

Comments

  1. O comparatie interesanta a performantei diverselor DI containers: http://philipm.at/2011/0808/
    - desi aparent n-ar trebui sa conteze, am simtit pe pielea mea 2 ani cat de lent poate sa fie Unity cand e vorba de grafuri mari de obiecte (sute/mii create simultan - aplicatie desktop)...

    ReplyDelete

Post a Comment

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP