Maandag 1 oktober, door met hoofdstuk 7 en 8, tempo maken. Hoofdstuk 7 gaat over dependency injection. Iets wat ik zelf niet gebruik, wel heb gezien in code van collega's en ik ook moet gaan toepassen. Je maakt je code er namelijk (beter) testbaar door. Zit er in je code een rechtstreekse verwijzing naar een logger die iets met een database doet, dan moet je ook bij het testen die database beschikbaar hebben. Voeg je in de constructor echter een interface van die logger door, dan kun je in testcode een soort dummy-logger maken. Hierna volgt uitleg over andere DI frameworks en het Service Locator Pattern. Een volgende paragraaf gaat over configuratie-gegevens. Een schok te lezen dat de web.config niet meer gebruikt wordt hiervoor. Wel kun je allemaal verschillende soorten formaat bestanden lezen (JSON, XML, INI) en zou je de web.config nog wel kunnen gebruiken, aangezien dat ook een XML-bestand is. Vervolgens een paragraaf over de gelaagde structuur. De presentatie-laag, de applicatie-laag, de domein-laag en de infrastructuur-laag. Het hoofdstuk sluit af met hoe je met excepties om moet gaan. Hoe het ServerObject voor LastError niet meer beschikbaar is, maar je dat doet met HttpContext.Features.Get... Hoe je met app.UseStatusCodePagesWithReExecute(...) zelf de statuscodes kunt afvangen en dus kunt bepalen of iemand een not autorized krijgt, een page-not-found of dat er een fout op de server opgetreden is. Mooie is ook dat je met app.UseDeveloperExceptionPage() kunt gebruiken om het yellow screen met stacktrace te krijgen op de ontwikkelomgeving en je dit zelf conditioneel in kunt stellen met de environment-variabele, env.IsDevelopment(). Een korte uitleg over Exception Filters en het loggen van excepties. Een leerzaam hoofdstuk!
In hoofdstuk 8 gaat over het beveiligen van je webapplicatie. Dus over authorize en authenticate. Dit kan met cookies, maar ook met een "bearer-token", wat vaak bij REST-services gebruikt wordt. Hierna komen we op de User Identity. Met het instellen van Claims kun je eigenschappen toewijzen aan de gebruiker. Ook externe authenticatie, dus inloggen via Twitter of Facebook. De User Manager van Microsoft heeft al een uitgebreide basis voor het beheer van gebruikers. Wachtwoord vergeten, lock-out. Ook in dit hoofdstuk komt ook weer terug dat je geen web.config meer gebruikt, had je daar de authorize-tag, die zul je nu zelf in code moeten implementeren! Dan de voorbeelden van het Authorize-attribuut, waarmee je kunt aangeven dat een bepaalde controller (BackendController) alleen door ingelogde personen met rol administrator aangeroepen kunnen worden. In ASP.NET Core zijn policies toegevoegd. Daarmee wil het framework de relatie tussen authorisatie en applicatie-configuratie uit elkaar trekken. Met het maken van een policy die je met functie .RequireRole("Admin").RequireClaim("editor", "contents") toevoegt, kun je zorgen dat voor dat deel je niet alleen admin moet zijn, maar ook editor moet zijn. Met .RequireAssertion(..) kun je dit nog tweaken, de .RequireClaim(...) is een "én" validatie, in RequireAssertion kun je ook "of" constructies maken.En ja, die policies kun je ook in je Razor-templates gebruiken. Dit hoofdstuk is net als hoofdstuk 7 leerzaam!
Op 2 oktober aan de slag met hoofdstuk 9. Het hoofdstuk met de titel Access to Application Data, dus "toegang tot applicatiedata". Voornamelijk databases dus. Zo wordt vermeld dat de ADO.NET toegang weer toegevoegd is (wat niet in versie 1 zat), maar waarbij je dus weer gewoon met connections, commands en adapters kunt werken. Het CQRS pattern wordt besproken (Command and Query Responsibility Segregation) waarbij je het lezen van data losgekoppeld wordt van het schrijven van data, waardoor je je datalaag "clean" houdt. Je hebt nu een Entity Framework Core. Er werd wel gebruik gemaakt van het Entity Framework 6.x, door dat in een losse library te zetten, maar daarbij beperk je jezelf dat de applicatie daardoor alleen nog onder Windows kan werken. Vervolgens worden de O/RM Frameworks besproken. Je hebt het Entity Framework, maar je hebt ook micro O/RM frameworks. Hierdoor mis je bijvoorbeeld het includen van gejoinde tabellen (support for relationships) en second-level caching. Voordeel daarvan is dat het je applicatie weer een stuk lichter qua belasting maakt. Voorbeeld is het Dapper Framework van Stack Overflow wat bij enkele query's tientallen keren sneller zou zijn. Daarna komt nog een overzicht van de Entity Framework Core taken, het injecteren van de DbContext, automatisch aanmaken van de database. Hierna nog de Data Tables, met Insert, Update, Delete. Het ziet er logisch uit en heeft veel overeenkomsten met het Entity Framework van ASP.NET. We eindigen met transacties, de DbTransactie. En nog een flinke waarschuwing over TransactionScope. Deze is toegevoegd, maar schijnbaar is het gedrag niet altijd zoals je dat zou verwachten. De laatste paragraaf gaat over async en de redenen om het wel en niet te doen. Alles asynchroon maken hoeft niet een verbetering van je applicatie te betekenen!
Op 3 oktober door met hoofdstuk 10 en 11. Hoofdstuk 10 gaat over het ontwerpen van een Web API. Uitleg over het teruggeven van JSON en andere formaten. Het verschil tussen REST en SOAP. Daarna volgt het beveiligen van een Web API. Basic authentication, Tokens, op basis van IP adres of door gebruik te maken van Identity Server. De standaard die je installeert bevat geen admin-interface, maar is via add-ons toe te voegen: http://www.identityserver.com/. Als ik dit zo lees moet ik hier zelf eens wat voor opzetten, als je zelf de code en koppelingen maakt blijft dit beter hangen.
Hoofdstuk 11 gaat over het posten van data vanaf de client side. Als je weet hoe je een post doet (met een form) en hoe je dat met jQuery/javascript doet, dan kun je dit hoofdstuk overslaan, want dat is het enige wat besproken wordt.
Op 4 oktober door met hoofdstuk 12 en 13. Hoofdstuk 13 gaat over client-side Data Binding. We beginnen met het verschil tussen het deels terugkrijgen van HTML en dat in de dom plaatsen of op basis van data de view aanpassen. Hierna volgen een aantal voorbeelden van verversen van data met JSON. Het Mustache-framework en de KnockoutJS-library. Met Knockout "bind" je de HTML-elementen aan de data, zodat als je of de data aanpast of de waarde in de input, vervolgens respectievelijk automatisch ook de data in de input aangpast wordt of in de data. En ook (natuurlijk) wordt AngularJS nog even benoemd. Dat framework wordt verder niet besproken, omdat het zo uitgebreid is, is daar een eigen boek over te schrijven.
Hoofdstuk 13 gaat over device friendly views en kun je eigenlijk wel overslaan. Modernizr wordt genoemd, het detecteren of je op een desktop, tablet of mobiel surft op basis van de UserAgent. Over de <picture> tag die je verschillende formaten kunt geven. Over het gebruiken van een CDN voor de afbeeldingen. Maar eigenlijk denk ik dat we al een stukje verder zijn. Google geeft je site een betere score als die goed qua mobiele weergave is. Steeds meer mensen zitten op hun mobieltje te surfen. Dus zoals je bij meertalige sites een dropdown hebt voor Engels, Duits, etc., zo zou je de site standaard als mobiele site kunnen tonen en laat je de bezoeker zelf via een dropdown kiezen voor de weergave op tablet- of desktopformaat.
Vrijdag 5 oktober, ook vandaag een hoofdstuk, hoofdstuk 14. Dit hoofdstuk gaat over de Runtime Environment van ASP.NET Core. Uitleg over de WebHost class en hoe je met CreateDefaultBuilder() de meest gebruikte opties standaard actief maakt. Vervolgens hoe je met WebHostBuilder().[eigen opties].Build() extra zaken kunt configureren, bijvoorbeeld UseIISIntegration(). De embedded webserver wordt besproken, dat is Kestrel. Flink bijgewerkt sinds versie 1. Hierna volgt een paragraaf over reverse proxies. Wil je Kestrel niet naar de "buitenwereld" zichtbaar maken, dan zet je er een proxy tussen, in dit geval kan dat Apache, IIS en nginx zijn. Hierna volgt nog uitleg hoe je Kestrel kunt configureren en HTTPS gebruiken. Daarna volgt nog een stuk over de ASP.NET Core Middleware, waarbij je rekening moet houden met eventuele opvolgende processen in de pipeline en dus eigenlijk altijd een await next() moet toevoegen. Voorbeeldcode voor het maken van Middleware Componenten en hoe je deze kunt registreren, ook via extension methods.
Dit hoofdstuk ging compleet over ASP.NET Core, over zaken waar ik (dus) nog niets van weet. Een leerzaam hoofdstuk!
Zaterdag 6 oktober, hoofdstuk 15. Dit gaat over het deployen van een ASP.NET Core Applicatie. Hoewel de syntax wat anders is, heeft het wel veel overeenkomsten met het deployen in de "klassieke" ASP.NET. Met de aanroep publish ... -r win10-x64 maak je een self-contained package, waardoor je alle DLLs meeneemt en dus niet afhankelijk bent van wat er op de machine waar de site op gaat draaien geïnstalleerd is. Het boek geeft aan dat de hoeveelheid bestanden dan al gauw de 96 MB bereikt, dus het is niet handig voor tig sites te doen om het vol raken van de schijf te voorkomen. De eerste paragraaf gaat over het publiceren en de profielen die daarbij aangemaakt worden. Daarbij kun je zelf bepaalde instellingen wijzigen. Zo compiled ASP.NET Core standaard de Razor-views, ze zitten in de DLL's. Wil je dat on-the-fly kunnen aanpassen, daarna inchecken in versiebeheer, zonder een volledig deployement te doen, dan kun je het onderstaande statement in het .csproj-bestand van het project te plaatsen:
<PropertyGroup>
<TargetFrameWork>netcoreapp2.0</TargetFrameWork>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
</PropertyGroup>
Wil je juist dat jouw applicatie een self-contained application wordt, dan moet je onderstaande in het .csproj-bestand van het project plaatsen:
<PropertyGroup>
<TargetFrameWork>netcoreapp2.0</TargetFrameWork>
<RuntimeIdentifiers>win10-x64;linux-x64</RuntimeIdentifiers>
</PropertyGroup>
Het publiceren vanuit Visual Studio, kan ook via de command-prompt, de CLI tools. Met het dotnet publish -statement doe je hetzelfde.
Dan volgt nog een uitleg over het deployen naar IIS. Hoe je de .NET CLR versie daar instelt (No Managed Code). Vervolgens hoe je naar Azure deployed en de verschillende versies die je daar beschikbaar hebt (Azure App Service en Azure Service Fabric). Op Apache kun je hosten op basis van Apache of nginx. Anders kun je het nog via Amazon Web Services en de Elastic Beanstalk toolkit doen. En daarna nog wat uitleg over containers.
Dan door het hoofdstuk 16, het laatste hoofdstuk. Dit gaat over "migration and adoption strategies". Oftewel, zou je je huidige klassieke ASP.NET applicatie gaan omzetten naar een ASP.NET Core applicatie? Dat hangt er allemaal vanaf. Ja, ASP.NET Core is op sommige punten wel tot 5x sneller. Het is multi-platform, dus je kunt het op Linux draaien. Maar het is ook echt toegespitst op MVC. Dus heb je een applicatie met webforms, gebruik je specifieke functies die nog niet in het Core Framework zitten, dan is het beter om het nog niet te gebruiken. Zoals de auteur al zegt in het boek, heb je problemen met performance/scaling, dan zal dat niet te maken hebben met het klassieke ASP.NET framework, maar eerder iets in je code wat niet goed gaat. Wel is de klassieke ASP.NET pipeline ingericht op WebForms. MVC en WebAPI is later bijgebouwd, maar maakt ook gebruik van die pipeline. Mocht je juist een nieuw project opzetten wat gebaseerd is op MVC en je hebt de keuze, dan zou Core eigenlijk wel je eerste keus moeten zijn. Al een aantal jaar is er weinig tot niets meer aan het klassieke ASP.NET gedaan, terwijl de programmeurs druk bezig zijn met Core, dus dit zou dan zoals te verwachten het framework van de toekomst moeten worden.