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

Why Database Modernization Matters for AI

  When companies transition to the cloud, they typically begin with applications and virtual machines, which is often the easier part of the process. The actual complexity arises later when databases are moved. To save time and effort, cloud adoption is more of a cloud migration in an IaaS manner, fulfilling current, but not future needs. Even organisations that are already in the cloud find that their databases, although “migrated,” are not genuinely modernised. This disparity becomes particularly evident when they begin to explore AI technologies. Understanding Modernisation Beyond Migration Database modernisation is distinct from merely relocating an outdated database to Azure. It's about making your data layer ready for future needs, like automation, real-time analytics, and AI capabilities. AI needs high throughput, which can be achieved using native DB cloud capabilities. When your database runs in a traditional setup (even hosted in the cloud), in that case, you will enc...

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

[Post Event] Azure AI Connect, March 2025

On March 13th, I had the opportunity to speak at Azure AI Connect about modern AI architectures.  My session focused on the importance of modernizing cloud systems to efficiently handle the increasing payload generated by AI.