*procédure stocké vs fonction (SQL) : une procédure stockée peut être utilisé seule, mais une fonction

doit être utilisé dans une requête.

*SOAP: ancien protocole d’échange d’information basé sur XML, plus lourds, exige plusieurs
spécifications de sécurité

*REST : supporte plusieurs format (json, text, xml…), plus léger et rapide, cross-plateforme plateforme
(windows, linux, Iot…)

*WCF : .net class library, sauf windows, non cross-plateforme, permet partager les données entre deux
projet .net avec SOAP, ne peut pas être utilisé avec JS

*Azure Functions : code being triggered by an event, on local/cloud, so can be debugged

*Azure Logic Apps : workflow triggered by an event, only on cloud so can’t be debugged locally

*Azure Functions and Logic Apps : to create complex orchestrations, an orchestration is a collection of
functions or steps, called actions in Logic Apps, that are executed to accomplish a complex tasks

*Azure Application Insights: application overview, examine la performance de l’application, nbr d’appel
d’API temp de réponse…

*Azure Automation Account : pour exécuter des batches planifier.

*BlazorWebSever : code C# exécuter coté serveur et HTML/CSS/JS coté client ;

*BlazorWebAssembly : toute l’app exécuté coté client, plus rapide, accès offline ;

*reflection : System.reflection System.Type collecter des infos sur le code (get classes, méthodes,
propriétés…)

*reference type: class, interface, delegate, record, dynamic, object, string (immutable => nouvelle
référence).

*value type : int, byte, float, struct,…

*indexer: permet d’indexer une instance de class comme un array.

*readonly : const assignée en runtime, peut initialiser dans le constructeur.

*const : cont assignée en compile time, à initialisé sur ligne, ne peut pas être initialiser dans le
constructeur.

*Task async await => Taks.FormResult(…) ; Task.Run(task) ; Task.WhenAll(tasks) : => run parallels async
tasks, traitement plus rapide, ne bloque pas l’interface (en cas desktop UI).

*async void: ne permet pas d’attendre l’exécution (no await) ni de catché les exceptions donc on ne
peut pas la tester, le processus se termine sans qu’on le save, donc utilisé async Task à la place de async
void (sauf pour les events, car elle ne supporte pas Task, ou dans un constructeur exemple 2 extension
méthode ci-dessous), en cas de retour utilisé async Task<typeRetour> ;

*await Task.Delay(…) vs Thread.Sleep(…) : la première pour une méthode async, et la deuxième pour
une méthode sync.
*SOLID : => - S -> SRP (Single Responsability Principle) : chaque classe/méthode doit avoir une seule
responsabilité, autrement dit si on veut la modifié ça sera pour une seule et unique raison, exemple :
méthode ajouter/supprimer ;

- O -> OCP (Open-Closed Principle) : classe doit être ouvert à l’extension, fermé à la modification, c’est-à-
dire le corps de la classe ne doit pas être modifié mais étendue (sauf bien sûr en cas de bug), exemple :
class employé étendue en manager en créant deux interfaces (simple employé et manager) ;

- L -> LSP (Liskov Subtitution Principle) : si une classe S est un sous-type d’une classe T, alors tout
instance de la classe T peut être remplacé par une instance de la classe S sans bug. Exemple : classe
employé avec méthode assign manager, manager hérite from emplyé (beug on ne pas lui assigner un
manager parce qu’il est manager) => solution : crée une classe de base Employé et deux interfaces
ISimpleEmployé (assigne manager), IManager.

- I -> ISP (Interface Segregation Principle) : une classe ne doit pas dépendre d’une interface qu’elle
n’utilise pas, exemple : séparer la classe employée (qui contient assigne manager) en plusieurs
interfaces : employeBase, employé, manager…

- D -> DIP (Dependency Inversion Principle) : les classes de haut niveau (métier) ne doit pas dépendre de
celle de bas niveau (DB access…), les deux doivent dépendre d’abstractions, ces derniers ne doivent pas
dépendre des détails mais les détails doivent dépendre des abstractions. Exemple : dependency
injection (Singleton Designe Pattern), création globale des instances dans une seule class (factory) pour
séparer les interfaces de leurs implémentations.

*Singleton Design Pattern : c’est un principe qui permet d’instancier une classe qu’une seule fois, crée
une instance private static readonly et sans paramètres. Exemple : dependency injection
services.AddSingleton<[interface], class>().

*Singleton : même instance utilisé tout au long de l’exécution, utile pour les services de cache, config,
rôles, htttpClient, statut, MessageBus… ;

*Scopped : nouvelle instance pour chaque appel ;

*Transient : toujours nouvelle instance pour chaque objet, utile pour DbAccess, FileAccess ;

*DRY (Don’t Repeat Yourself) : éviter les redondances de code, exemple : DB access.

*delegate : type qui permet de passe une fonction en paramètres d’une autre fonction (pointeur de
fonction en C/C++), pour crée des méthodes anonymes.

*anonymous, labda expression (LINQ) : contient pas de nom, classe anonyme crée des class en lecteur
seule (records, DTOs) -> var test = new {…}, méthode anonyme affecté à des variables de types
déléguées, crée une fonction en une seule ligne (~JS), labda expression permet de crée une méthode
anonyme ( (paramètres) => {…} sans retours ou Func<types>(paramètres) => {…} avec reours), des
variables qui pointe sur des fonctions.

*overloading (surcharge) : polymorphisme => définir plusieurs méthodes dans la même classe, avec
même nom mais des signature (paramètres) différentes. Exemples : add(int a, int b), add(int a, int b, int
c).
*overriding (redéfinition) : polymorphisme => redéfinir une méthode de la classe mère depuis la classe
fille en utilisant les mots clé (abstract -> sans corp ou virtual -> avec corp et override). Exemple :
calculerSurface() implémentation en fonction du type : rectangle, triangle, trapèze…

*Records in C# 9.0 : classe (avec parenthèses et point-virgule) à utiliser pour des propriété immuable (ne
peuvent pas être modifié) avec déclaration simple, exemple : DTOs soit sûr que l’objet n’est pas modifié
lors de transfert des données, public record RecordTest(string fullName) ; RecordTest recordTest =
new(‘’Test’’), affichage en format string recordTest.ToString() => RecordTest { fullName = Test }.
Optimisation de la mémoire, deux propriétés record avec les mêmes valeurs pointes vers la même case
mémoire.

*Extension method : permet d’ajouter des nouvelles fonctionnalités à des classes (qu’on ne contrôle pas
forcément) sans les modifiés, exemple 1 : public static void LogError(this CustomClass customClass,
string message) { Console.WriteLine(message) } CustomClass customClass = new () ;
customClass.LogErro(‘’testMessage’’) ; exemple 2 : utilisé await dans un constructeur, ou pour catché les
exceptions, code : public static async void CustomAwait(this Task task) { await task ; }, async Task
MyTask() { await Task.Delay(3000) ; } MyContrcuteur() { myTask. CustomAwait () ; }

*yield : pour crée une fonction en boucle (iterator function) permet de fait appel d’une fonction à
l’intérieur d’une instruction for ou foreach.

*HashSet : List of unique values not null;

*GUID : identifiant globale et unique au monde basé sur l’adresse MAC.

*MVC : contrôleur est le point d’entrée, c’est le handel request, qui reçois/envoi les
requêtes/commandes, il stock les données dans les modèles, ces derniers met à jours les views, utilisé
principalement pour les applications Web, support TDD et les requêtes asynchrones

*MVVM : code piloté par les événements, la vue est le point d’entrée, le viewModel c’est le binding
entre le view et le model (bidirectionnel), utilisé principalement pour les applications desktop/mobile
(WinForms, WPF, UWP, Xamarin…) avec générateur de code UI, support tests unitaires

*.NET Framework 4.8 dernière version, pas de nouvelles versions par la suite, moins rapide, supporte
que version <= 7.0 de C#.

*.NET 6.0 (inclus que .NET Core et Xamarin et pas .NET Framework, continuité de .NET Core avec la
version 4.0 sauté pour ne pas confondre avec .NET Framework 4.0 version) : open source, cross-
plateforme, plus rapide, supporte les dernières versions de C# (10.0), Swagger intégrer pour ASP.NET
MVC Core.

*.NET Standard 2.1 : pour crée des librairies supportées par toutes les autres versions de .NET (Core,
Framework, Xamarin…).

*Microservices : ensemble de services séparer (Single Responsability Principal), peut chacune utilise une
techno différente de l’autre, chaque service est indépendant, ne connait pas l’implémentation de l’autre
service, si un service tombe en panne ça ne va pas affecter les autres services, chaque service peut être
déployé dans son propre container (docker) ainsi que sa propre scalabilité, et peut avoir sa propre base
de données ;
*Docker : permet de packager une app sous format d’une image docker et l’exécuter sous format de
container sur n’importe quel environnement qui support docker, ce qui rend faible les dépendances et
assure le déploiement et le fonctionnement de l’app sur n’importe quel environnement, et évitera de
mettre en place plusieurs OS (système d’exploitation/machine virtuelle) pour hôster l’app (services) en
utilisant un OS qui hôste plusieurs container ;

*EF (Entity Framework) Core 6.0 : crée pour .NET 6.0, étapes :

- Crée classes: validations => Required, MaxLength(nbr), Column(TypeName = “type”);

- Connecter db ;

- Installer nuget packge Microsoft.EntityFrameworkCore.SqlServer ;

- Crée dbContexte qui contients dbSet (tables) ;

- Ajouter dbContext au services (Startup.cs) avec dependency injection system :

services.AddDbContext<MyDbContext>(options => {…}) ;

- Définir la chaine de connexion (connection string) dans appsettings.json ;

- Installer Mircrosoft.EntityFrameworkCore.Tools ;

- Sous Package Manager Console taper :

=> Add-Migration migrationName -> permet de crée le code de la base de données ainsi en cas de
modification de mettre à jours ce code (add/update/delete column…) ;

=> Update-Database -> permet de crée/modifier la bd.

- Ajouter dbContext to PageModel (private readonly MyDbContext _db; + constructeur => MyDbContext
db ; _db = db ;) ;

- Remplir la bd => exemple : _db.AddRange(…) ; _db.SaveChanges() ;

*Mediator Pattern : en cas de multiples dépendances, inclure un service intermédiaire (.NET -> MediatR)
à travers des handlers, plus on a une grande application plus on aura besoin d’un grand patron de
conception, on n’aura pas besoin d’utilisé les patrons de conceptions Mediator ou CQRS pour des petites
applications.

*CQRS (Command Query Responsibility Segregation) => sépare la lecture de l’écriture (CRUD => R :
Query ó CUD : Command), séparation de responsabilité, optimisé les performances, évolutivité, sécurité,
empêcher les cmds de màj à provoquer des conflits, séparer BDs/Modèles/Services/Rôles (une pour la
lecture et l’autre pour l’écriture) éviter LightDTOs, C#.NET CQRS Framework -> MediatR 9.0 : équilibre
entre la taille de l’application et la grandeur du patron de conception (architecture), ne pas perdre des
données (stocker tous les événements et les redéclencher), système de log (stock différents état d’un
objet), supporte plusieurs requêtes, exemple étapes :

- Crée projet class library (.NET Standard ou .NET) ;

- Crée DataAccess : constructeur pour remplir les data, méthodes : GetPersonList(), InsertPerson(…) à
utiliser dans les handlers ;
- Installer package MediatR ;

- Crée Queries : sous forme de records (for readonly, mutable, C# >= 9.0) implemented from
IRequest<List<Person>> (du framework MediatR) => Crée Handler : implement IRequestHandler<
GetPersonListQuery, List<Person>> avec injection de dépendance de data access, méthode Handle
return Task.FromResult(_data.GetPersonList()) ;

- Injection des dépendances : services.AddSingleton<IMyDataAccess, MyDataAccess>; et installer

package MediatR.Extensions.Microsoft.DependecyInjection =>
services.AddMediatR(typeof(MyLibraryEntryPoint).Assembly) ; au niveau des pages html @inject
MediatR.IMediator _mediator ; await _mediator.Send(new GetPersonListQuery()) ;

- Crée Commands : exemple InsertPersonCommand => record avec paramètres, implement from
IRequest<Person>; => crée handler implement from IRequestHandler<InsertPersonCommand, Person>
avec injection de dépendance de data access, Handle return Task.FromResult(_data.InsertPerson(…)) ;
Post API insertPersont(…) -> await _mediator.Send(new InsertPersonCommand(…)) ;

- Command -> command bus (traiter les commandes en différé) -> command handler -> command
store ;

- Requête -> dénormaliser -> Event bus (mettre à jour le modèle de données) -> Event handler -> Event
store ;

*DDD => unifier langage technique et métier, utilisé les mêmes termes, couche métier permet de valider
les commandes -> déclencher les événements

- API -> couche passerelle entre l’application et les utilisateurs finaux, valider les entrées avant de les
envoyés à la couche domaine (DTOs) ;

- Domaine -> définis les concepts, les comportements et les règles, implémenter par les autres couches ;

- Infrastructure -> Interagir avec la base de données, gérer les exceptions (exp. : ADO.NET, EF).