Entity Framework Core 7 est déjà sorti il y a quelque temps maintenant (le 8 Novembre 2022 si vous n’avez pas cliqué sur le lien…), mais je souhaitais revenir sur l’arrivée de la stratégie TPC (Table Per Concrete), et au passage, en profiter pour présenter les différentes possibilités pour gérer l’héritage avec EF.
Entity Framework Core Entity Framework Core est un ORM (aka. object-relational mapping) dédié au monde .NET. Il succède à Entity Framework, et vient lui apporter légèreté et extensibilité ainsi que le support du multiplateforme et la diffusion du code en open source.
J’ai récemment eu besoin de mettre en place un mécanisme permettant l’ajout automatique de tags sur des ressources Azure. Il s’agissait de positionner des tags pour tracer les modifications sur des ressources (auteur et date de création/modification). J’en profite donc pour faire un feedback technique, et aborder au passage la brique Azure Event Grid.
Comment ça fonctionne ? Le fonctionnement est globalement assez simple, et ne nécessite que 2 composants :
Dans mon article sur la scalabilité et la haute disponibilité, j’avais rapidement abordé le sujet du pattern CQRS. Aujourd’hui, nous allons voir un peu plus en détail les concepts et le fonctionnement de ce pattern.
CQRS, qu’est-ce que c’est ? CQRS, pour Command Query Responsibility Segregation, est un pattern reposant sur le principe de la séparation des opérations de lecture (Query) et d’écriture (Command)
Ce pattern est né du constat que les besoins, fonctionnels ou techniques, d’une application sont souvent très différents selon que l’on cherche à lire ou à modifier une donnée.
Dans mon précédent article sur la scalabilité et la haute disponibilité, j’avais abordé le concept d’architecture microservices. Je vais aujourd’hui détailler un peu plus ce type d’architecture qui répond à de nombreuses problématiques rencontrées par les entreprises.
Dans son article Who Needs an Architect?, Martin Fowler développe sa propre définition de l’architecture :
À première vue, l’architecture d’une application se résume en la décomposition de la totalité du système applicatif considéré en éléments constitutifs plus simples, aux rôles, responsabilités et limites bien identifiés.
Vaste sujet ! Dans cet article, nous allons parler clean code, dette technique, refactoring et anti-patterns. Il fait suite à la série sur les designs patterns que vous pouvez retrouver ici :
Les design patterns et les principes SOLID en développement logiciel Les patterns creationals Les patterns structurals Les patterns behaviorals Tout logiciel est constitué de code, et c’est la qualité de ce code qui va faire d’une application une application de qualité.
Troisième et dernière catégorie de pattern que je vais aborder, les behavioral patterns ou patrons de comportement. Il en existe 11 et ils permettent de définir comment organiser nos objets pour que ceux-ci collaborent.
Si jamais vous les avez ratés, je vous invite à (re)lire les parties précédentes :
L’introduction sur les design patterns Les patterns creationals Les patterns structurals Chain of responsibility Ce pattern permet de séparer les objets émetteurs de requêtes et les objets chargés de recevoir et traiter les requêtes.
Je vais aujourd’hui m’essayer à un nouveau format d’article. Celui-ci à pour objectif d’aborder un sujet technique que je trouve intéressant mais de manière moins approfondie que d’habitude, c’est-à-dire avec peu ou pas de code. L’idée est de se familiariser avec le sujet pour être capable d’en parler et d’ouvrir des portes pour creuser plus profond si nécessaire (ce sera le cas avec ce thème, j’ai plusieurs articles d’approfondissement dans ma “bannette”).
Après les patterns creationals (que vous pouvez retrouver ici), je vais maintenant aborder les structural patterns ou patrons de structure. Il en existe 7 et ils permettent de définir comment organiser nos objets. Si vous le souhaitez, vous pouvez retrouver l’introduction sur les design patterns ici.
Adapter L’objectif du pattern Adapter est de faire passer quelque chose pour autre chose sans perturber le reste de l’application. Il est ainsi capable de rendre compatible deux éléments ne parlant pas le même langage, par exemple, une application travaillant avec le format XML mais utilisant un service de données qui renvoi du JSON.
Suite à l’article d’introduction, les premiers types de patterns que je vais aborder sont les creational patterns ou patrons de création. Il en existe 5 et ils permettent de définir la manière de faire l’instanciation et la configuration des classes ou des objets de manière souple tout en minimisant le couplage et en maximisant la réutilisation du code.
Singleton C’est probablement le design pattern le plus connu et le plus utilisé.
Je souhaite revenir aujourd’hui sur un sujet qui, à mes yeux, est très important mais malheureusement assez méconnu des développeurs : les design patterns. Lors des quelques entretiens que j’ai pu faire passer, je me suis rendu compte que cette notion est soit mal maitrisée (quelques mots-clés/buzzword cités ça et là mais sans réelle explication derrière) soit carrément inconnue ! Je trouve ça dommage car c’est quelque chose de très utile dans son travail quotidien et nous allons voir pourquoi dans cet article.