Bij het door mijn blogs heen bladeren kwam ik een link tegen die ik had opgenomen met een verwijzing naar .NET Core en het Entitity Framework Core ( link ), waarbij ik tijdens het naar beneden scrollen de term Dependency Injection tegen kwam met deze verwijzing ( link ). Een goede manier om je code onafhankelijker te maken, waardoor het ook (beter) te testen is. Wel valt me op dat in het verleden wel eens het stramien was, begin je code met alle juiste waardes en vang onderaan alle excepties af, in de voorbeelden lijken juist alle excepties eerst afgevangen te worden en ga je daarna door met het "ideale pad".
Ook zie ik links in het menu onderaan de pagina "PDF downloaden" staan. Na hierop geklikt te hebben duurt het even (ik heb niet een supersnelle internetverbinding), maar na verloop van tijd heb je dan een PDF van 2.641 pagina's (33.5 MB). Mocht je een e-reader hebben en je willen verdiepen in ASP.NET Core 2.1 dan is dit een mooie manier om door de informatie heen te bladeren. In het begin wordt verwezen naar de beschrijving van Razor-pages ( link ). Hoewel ik zelf al daarmee gewerkt heb, is dit een duidelijke toelichting, ook omdat je hier andere mogelijkheden hebt (door @page bovenin toe te voegen kun je de .cshtml ook los aanroepen).
De ontwikkelingen gaan door, want ik kwam op Twitter dit blog-item tegen over ASP.NET Core 2.2 die binnenkort uitgebracht gaat worden. Je kunt hier lezen wat er gaat gebeuren: link.
De beste manier om de mogelijkheden te verkennen en ervaring op te doen is door te beginnen. Maak wat. Dus inmiddels ben ik begonnen met een voorbeeld, je maakt je eigen ToDo-api. Je kunt dat ook zelf doen door gewoon de stappen uit de PDF (of vanaf de website) te volgen. Niet heel erg vernieuwend, maar een "in-memory-database" kende ik dan weer niet. Erg handig om mee te testen!
In Startup.cs voeg je daarvoor dit toe:
using Microsoft.EntityFrameworkCore;
public void ConfigureServices(IServiceCollection services)
{
services.AddDbContext<TodoContext>(opt =>
opt.UseInMemoryDatabase("TodoList"));
}En je maakt in je Models-map een class aan met de naam TodoContext.cs met deze inhoud:
using Microsoft.EntityFrameworkCore;
namespace ToDoApi.Models
{
public class TodoContext : DbContext
{
public TodoContext(DbContextOptions<TodoContext> options)
: base(options)
{
}
public DbSet<TodoItem> TodoItems { get; set; }
}
}En je maakt dus een public class "TodoItem" aan die bepaalde eigenschappen heeft.
Zelf gebruik ik Fiddler om te controleren wat voor verkeer er over de lijn gaat, welke requests nu lang duren, maar Microsoft gebruikt vaak Postman in haar voorbeelden. Postman kun je hier downloaden: link.
Na deze basic opzet wordt er een interface (HTML pagina met jQuery) toegevoegd. Hiervoor moet je de static files en default files aanzetten. Daarmee zorg je dat .css en .js bestanden op te vragen zijn en dat er niet een volledige URL gedefinieerd hoeft te worden.
In Startup.cs voeg je in Configure de volgende 2 regels toe:
app.UseDefaultFiles();
app.UseStaticFiles();
Tot zover de oplossing in Visual Studio. Het volgende deel is hetzelfde project, maar dan in Visual Studio Code. Je start daarbij vanuit de DOS-prompt of de terminal in Mac/Linux de volgende commando's:
dotnet new webapi -o TodoApi
code TodoApi
Het builden en runnen van het project gebeurt op basis van HTTPS. Je kunt in de settings wel aanpassen dat het op HTTP moet, maar als je het project online gaat plaatsen zul je waarschijnlijk ook op HTTPS je code uitvoeren. Je moet daarvoor op je "localhost" een eigen HTTPS-certificaat installeren. Dat doe je door in de terminal onderstaand commando uit te voeren:
dotnet dev-certs https --trust
Vervolgens krijg ik nog wel een foutmelding in onder andere Chrome, omdat het een "self-signed" certificaat is wat standaard niet vertrouwd wordt. Maar dat zie je alleen in de adresbalk, verder werkt het gewoon. In FireFox wordt de boel compleet geblokkeerd. Daar moet je via Geavanceerd, Uitzondering toevoegen... en vervolgens bevestigen het eigengemaakte certificaat vertrouwen en kun je je project testen. Eerlijk gezegd werk ik zelf het meest in Chrome, maar ik vind de interface van het JSON resultaat in FireFox er mooi uit zien. Je ziet het eerst als data, de andere weergaves kun je onder de tabs Onbewerkte Gegevens (de platte tekst zoals je die in Chrome ziet) en Headers zien. In "Headers" zie ik dan weer een antwoord van een vraag voor het Microsoft examen terugkomen, de browser stuurt in de headers "Accept-Encoding: gzip,deflate" mee, zodat de webserver weet dat de data in GZIP-formaat teruggestuurd kan worden. Scheelt weer bandbreedte :)