Možda se nisu oglasile fanfare, ali prije oko godinu dana počelo se raditi na specifikaciji i implementaciji nove verzije ASP.NET frameworka. Ne ASP.NET 5 ili 6, nego bih ja to slobodno mogao nazvati ASP.NET 2.0. Vezija 1 je izašla 2002., a verzija 2 2014!

Ovaj hudo je poludio, sigurno vam je prvo palo na pamet, ali ovako korijenite promjene, gdje se razvoj jezgre, arhitekture i cijelog tehničkog dizajna počeo raditi iz nule, odnosno gotovo od File/New Project, a ne od File/Load “System.Web”, govori o težini i veličini nove verzije. Naravno da Microsoft, poslovično pragmatičan i oprezan što se tiče kompatibilnosti unazad, pokušava i dalje paralelno razvijati WebForms i MVC, a novije frameworke poput WebAPI i SignalR prilagoditi novoj arhitekturi, tako da će tranzicija na OWIN biti najvjerojatnije bezbolna i transparentna. Što to znači?

WebForms i MVC ostaju gdje jesu, ovisni o System.Web dijelu .NET frameworka. Ali sve ostalo što izlazi iz MS radionica će biti OWINizirano.

OWIN (Open Web Interface for dot Net) je najlakše opisati sa ovom linijom koda:

using AppFunc = Func<IDictionary<string, object>, Task>;

niti ostatak specifikacije nije nešto složeniji, uz par pravila i ograničenja sadrži spisak ključeva i tipova koji se kriju iza ove IDictionary<string, object> varijable. Povratni tip Task nam govori da je asinkrono procesiranje ugrađeno u samu specifikaciju.

Ali što znači ovaj linija uopće? Najjednostavnije, radi se o pipelineu (cjevovodu?), gdje su komponente (Middlelware) spojene jedna za drugom, prosljeđuju ili prekidaju izvršavanje upita. Jedna komponenta na primjer može biti logiranje, jedna autentifikacija, zatim sam web framework poput Nancyfx, ili REST framework poput WebAPI ili ServiceStack.
Našu aplikaciju čine niz povezanih komponenti, gdje smo mi odabrali samo ono što želimo da se izvršava. Ako nam ne treba session management, nećemo tu komponentu uključiti u pipeline, samim time niti “platiti” to performansama ili memorijom.

Implementacija OWIN specifikacije od strane Microsofta se ove Katana. Ona omogućava izvršavanje OWIN komponenti u IIS-u ili pak self-hostanu unutar druge aplikacije koristeći HttpListener (Nuget: Microsoft.Owin.Host.HttpListener), koristeći postojeću funkcionalnost unutar System.Web imenskog prostora.
Projekt pod nazivom Helios (Nuget: Microsoft.Owin.Host.IIS) je potpuna zamjena za System.Web u korištenju IIS-a, gdje su svi nativni pozivi na IISu nanovo napisani, a sve to zajedno donosi agilnost, puno brži release cycle, i svakako puno bolje performanse.

Evo kratki primjer kako dodati OWIN-baziranu web aplikaciju u postojeći projekt (WPF ili konzolna aplikacija, da stvar bude zanimljivija). Prvo dodajte Nubget pakete: 

Microsoft.Owin.Host.HttpListener
Microsoft.Owin.Hosting

Pokretanje Katana web servera na portu 12345:

WebApp.Start<Startup>(“http://localhost:12345”)

Sama Startup klasa prema konvenciji mora imati metodu Configuration. U njoj smo definirali 3 middleware komponente

Za LoggingMiddleware koristili smo baznu klasu, i napravili vlastitu komponentu:

Ovaj vrlo jednostavni primjer će potom raditi i na IIS-u, IIS expressu, ili pak nekom drugom serveru (Linux), jer korištene komponente ne referenciraju niti jednu klasu iz System.Web imenskog prostora.

Postojeći WebForms i MVC frameworci najvjerojatnije se nikada neće moći pokretati na nekom OWIN hostu, ali postoji i niz drugih odličnih frameworka koji ih mogu više ili manje uspješno zamjeniti (Nancy, Simple.Web, …)

Šlag na kraju je lakoća in-memory testiranja, bez potrebe za pokretanjem servera i otvaranjem portova, upotrebom Nuget paketa Microsoft.Owin.Testing i xunit-a

Nadam se da je ovaj kratki prikaz OWIN pomogao u njegovom shvaćanju, i da će te pronaći scenarij za iskoristiti ga!

Hello my english speaking visitors! As you maybe noticed, this blog is on croatian language, but just for your reading pleasure, this post is readable for more than 100 croatian speaking asp.net devs

Now, back to the subject! Today is found nice link on www.asp.net home page, about using more than one model for MVC view, check it out here: http://honestillusion.com/blog/2013/11/11/Using-a-second-model-object-in-an-aspnet-mvc-view/

This will be my (short) take on this subject, offering yet another approach. We all know that MVC view can receive just one model type, that’s later available with @Model, and stuffing additional data to ViewBag is, or lets say, feels just wrong. And we’re to lazy to write a class that encapsulates all the types we need, as properties.

We can use (drum roll), yes, you are right my dear reader, TUPLE data structure! Someone may ask, what the heck are you talking about!? And you would give him some link like this one; http://www.dotnetperls.com/tuple or this one http://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx and he would see how Tuple is nice and useful data structure, present in .NET from version 4 (I think, or 3. Or maybe 3.5. I don’t know)

So, without further ado, let’s see some code. Like controller:

And the view:

I’ll not show you my model code, because those are just plain old classes. Nothing interesting there.

And that’s the whole science with this technique! Just encapsulate as many types you want inside Tuple data structure, specify Tuple signature in view, and you get all the intellisense beauty in your Razor view!

Downside of this approach would be, let me think, maybe this: you can’t really tell what’s Model.Item1 and Model.Item2 just by looking at it, if you send tuple with two items of the same class it’s hard to tell which one you need to use, you brake concept ‘one view one model’ (I just invented this concept, but you get the point), etc. So, use it wisely, because with great power comes great responsibility (think about poor junior dev who will need to maintain your app few years from now)!