Týždeň 2021-34

Pred tridsiatimi rokmi do newsgroupy (dnes už len známe na adrese https://groups.google.com/) napísal Linus Torvalds príspevok, o tom, že vytvoril nový free operačný systém s názvom Linux, ktorý je len hobby, a nebude veľký ani profesionálny.


Toto je sprievodná diskusia k pôvodnej téme na https://blog.vyvojari.dev/vlko-week-2021-34/

To dotnetove APi od komunity vyzera super. Ani nespocitam kolkokrat som skladal cestu k binarke, a tiez som niekolkorat robil Chunk pre EF.

@vlko preco preferujes prave Lamar?

Potrebovali sme IoC, ktory by nahradil ten default co je v .NET Core. Mame nad tym iba jednoduchu abstrakciu a ked sme zacali konverziu na .NET Core, tak mi prisiel ako celkom vyhovujuce riesenie. Akurat to bolo postavene na knownledge StructureMap a len pre potreby .NET Core, cize ziadne obsolete dependencies a zatial sme si veru nemohli stazovat.

A co konkretne ti v zakladom ServiceCollection/ServiceProviderovi chybalo?

1 Like

Autodiscovery, ako je v Lamar Scan, nechce sa nam vsetky definicie pisat (to sa nejak da aj v Microsoft.Extensions.DependencyInjection napisat, ale tak lepsie ked je to zabudovane, nech nemusim pracne debugovat). Mame pre rozne verzie db viac instancii IoC cez factory pattern. A aj resolving cez kluc velmi vzacne pouzivame.

Ja osobne by som radsej natrafil na takyto kod:

var widgets = Assembly.GetExportedTypes()
   .Where(t => t.IsAssignableTo(typeof(IWidget))
   .ToArray();

foreach(Type widget widgets) 
{
    services.AddSingleton(widget)  
}

Trochu mi vadi, ze Lamar wrapol cely .NET IoC svojskym API, ked vsetky spomenute features mohol urobit jednoducho pomocou extension metod pre IServiceCollection, resp IServiceProvider;

PS: Aj vam sa stava, ze na konci vety napisete bodkociarku? :smiley:

neriesi NuGet Gallery | Lamar.Microsoft.DependencyInjection 6.0.0 prave tento problem? Lebo mi to takto pouzivame + light wrapper nad Lamar a v princípe sme nad výberom IoC nezávislý.

Asi ano, ale:

Lamar je IoC postavene nad ServiceCollection a potom tu mame dalsi nuget, ktory wrapuje Lamar tak aby sa dal jednoduchsie pouzit s ServiceCollection.

Podla mna je to postavene na hlavu a ma to zmysel iba pri upgradovani zo StructureMap.

Takto by to davalo zmysel:
Lamar.Microsoft.DependencyInjection by sa volal Microsoft.DependencyInjection.Lamar a uz by nemal ziadne dalsie zavislosti, okrem Microsoft.Extensions.DependencyInjection.*

Scan assembly nad defualtnym IoC kontainerom poskytuje napriklad Scrutor.

Ale autodicovery pre IoC container som opustil na zaklade filozofie SimpleInjectoru a toho, ze to povazju za antipatern (za mna to neprinasa vyhody, okrem usetrenia par riadkov kodu) - https://docs.simpleinjector.org/en/latest/decisions.html. Ale chapem, ze v istych pripadoch sa to moze hodit (napr. s pouzitim MediatR).

Mame pre rozne verzie db viac instancii IoC cez factory pattern.

Ten resolvujete v runtime a v jednej instancii aplikacie moze byt konekcia na rozne databzy?

A aj resolving cez kluc velmi vzacne pouzivame.

Na co ho pouzivate? Ja som na to zatial nemal motivaciu.

Jo nielen rozne databazy, ale aj druhy databaz, okrem RavenDB maje aj mssql aj postgresql

Teraz pozeram, ze uz nie je pouzivany, ale ak si dobre pamatam, tak sme ho pouzivali pre rozdielny email provider, "local"poslal mail cez smtp a s “remote” cez mail branu. Ale uz mame LocalEmailProvider a RemoteEmailProvider:)