Dotnet

Laat EF Core je domein niet modelleren Ik ga meteen met de deur in huis vallen: De belangrijkste reden om automatisch voor EF Core te kiezen, is door AI een stuk minder overtuigend geworden. Jarenlang was het argument simpel. Met EF Core schrijf je minder SQL, minder mappingcode en minder repetitieve persistencecode. Je bouwt dus sneller dan met ADO.NET of een micro-ORM zoals Dapper. Dat argument was terecht. Alleen is de prijs van die expliciete code intussen drastisch gedaald. Een coding agent kan vandaag in veel gevallen een query, een persistence model, de mapping naar je domein en de bijbehorende tests genereren. ...

Odoo-modulariteit: razendsnel aanpassen, voorzichtig upgraden Odoo is tegelijk een Belgisch softwarebedrijf en een suite van bedrijfsapplicaties. CRM, verkoop, boekhouding, voorraad, e-commerce en planning lijken voor de gebruiker losse apps, maar draaien technisch op hetzelfde platform en delen één geïntegreerde applicatie- en datalaag. De Community-editie is open source; daarbovenop biedt Odoo een Enterprise-editie en commerciële diensten aan. Die brede functionele dekking is indrukwekkend, maar niet het interessantste aan Odoo. De echte superkracht is hoe gemakkelijk een module een bestaande applicatie kan uitbreiden. Een CRM-module kan velden toevoegen aan een contact, Verkoop kan knoppen op hetzelfde contactformulier plaatsen en een maatwerkmodule kan vervolgens het gedrag van beide aanpassen—zonder de broncode van die modules te kopiëren. ...

Waarom union types? Stel: een huisdier in jouw domein is altijd een kat, hond of papegaai — en nooit iets anders. Hoe modelleer je dat in C#? Er zijn meerdere aanpakken, elk met andere garanties van de compiler, andere leesbaarheid en andere gevolgen voor je EF Core mapping. In dit artikel loop ik vijf aanpakken langs op hetzelfde voorbeeld: Pet = Cat | Dog | Parrot. Aanpak 1 — object (de “het is toch gewoon een object”-aanpak) De meest naive oplossing: stop alles in een List<object> en match op type. ...

Intro Event-driven architecture wint snel aan populariteit in .NET-teams. Vroeg of laat komt dan deze gedachte: “Hoe moeilijk kan het zijn? We spreken gewoon rechtstreeks met Azure Service Bus. We bouwen zelf wel wat we nodig hebben.” Mijn hot take: Zelf een event-driven “mini-framework” bouwen bovenop Azure Service Bus (of RabbitMQ, Kafka, …) is bijna altijd een verspilling van tijd en geld. Niet omdat je het niet kan bouwen, maar omdat je de echte kost onderschat. ...