[C#] Injection de dépendances

C’est un sujet assez populaire dans le monde du .NET. Une pratique de développement de plus en plus utilisée par les équipes de développement.

Nous allons voir ici de quoi il s’agit, et les erreurs à éviter dans l’implémentation d’injection de dépendances.

Définition

Une injection de dépendance est un pattern qui fait parti de ce que l’on appelle les IoC (Inversion Of Control) Containers. En .NET on en retrouve plusieurs parmis les plus connus : Spring.NET, Unity, Ninject… L’un ou plusieurs de ces noms doivent vous dire quelque chose 🙂

A savoir toutefois :

  • Vous pouvez effectuer une injection de dépendances sans avoir besoin d’un IoC container ou d’un outil externe.
  • Vous pouvez utiliser un IoC container sans faire d’injection de dépendance et, en fait, c’est une pratique extrêmement courante (qui n’est pas la plus top).

Partons d’un exemple de code et implémentation simple :

public class CustomerService : ICustomerService
{
private readonly CustomerRepository _customerRepository;

public CustomerService ()
{
_customerRepository = new CustomerRepository();
}

public Customer GetCustomerById(int id)
{
return _customerRepository.GetCustomerById(id);
}
}

Dans ce cas présent, notre service « CustomerService » est fortement dépendant du repository « CustomerRepository ». Il en a effet besoin pour requêter la liste des clients et en récupérer un en particulier.

Comment dans ce cas utiliser l’injection de dépendances pour éviter ce fort couplage ? On va utiliser une interface qui va servir de contrat pour le repository « CusomerRepository » :

public interface ICustomerRepository
{
Customer GetCustomerById(int id);
}

public class CustomerService : ICustomerService
{
private readonly ICustomerRepository _customerRepository;

public CustomerService (ICustomerRepository customerRepository)
{
_customerRepository = customerRepository;
}

public Customer GetCustomerById(int id)
{
return _customerRepository.GetCustomerById(id);
}
}

Et c’est ainsi fait ! En interfaçant ainsi notre repository, on découple ce lien entre notre service Customer et le Repository.

Il nous faut ensuite, via l’utilisation d’un des containers vus plus haut, configurer le mapping (Interfaces et implémentations) de nos injections de dépendances. Prenons ici l’exemple avec Unity :

private static IUnityContainer BuildUnityContainer()
{
var container = new UnityContainer();

container.RegisterType(typeof (ICustomerRepository), typeof (CustomerRepository));

return container;
}

A noter : ce mapping peut aussi bien se faire dans un app.config ou web.config. Ici nous l’avons fait directement en dur dans le code. Il peut être judicieux, pour des questions d’évolutivité, de placer ce mapping dans des fichiers de configuration !

Lien intéressant sur le sujet : https://www.martinfowler.com/articles/injection.html

Partagez:

TFS au quotidien : les Work Items

En tant que développeur, et travaillant avec Team Foundation Server (TFS), l’une des tâches récurrentes auxquelles on doit s’atteler est celle des Work Items (ou éléments de travail).

Présentation

  • Un work item est un élément de travail sous TFS sur lequel va intervenir un membre de l’équipe ;
  • Le Work Item peut être de différents types : Bug, Taks, Issue, User Story … Sachant que les Work Items peuvent être liés entre eux (par ex : on va lier un ensemble de WI de type Tasks à un WI de type User Story) ;
  • Suivit : c’est sur ces éléments que l’on va aussi pouvoir renseigner les temps de développement : estimation (en heures), temps consommé, temps restant … ;
  • Il est possible via TFS de personnaliser les modèles de Work Items pour les adapter au projet.

WI01

A savoir que les Work Items sont utiles pour les différents membres de l’équipe :

  • Pour le développeur, cela permet à celui-ci de gérer son temps, estimer la durée des tâches sur lesquelles il intervient, alerter le chef de projet en cas de risque de dépassement ;
  • Pour le chef de projet : permet d’avoir une vision globale de la durée d’un sprint, constater les éventuels dépassements et tâches chronophages ;
    • Notez qu’il est possible de créer les Work Items directement depuis le logiciel MS Project, et que l’intégration Excel fonctionne (possibilité d’extraire les Work Items dans une feuille Excel et les mettre à jour directement via cette feuille).
  • Cellule de qualité : on peut choisir, lors d’un archivage de code, de forcer le développeur à « lier » son archivage à un Work Item. Ceci par soucis de traçabilité des modifications apportées au code source.

Enfin, une astuce quant à la saisie des temps passés :

  • En une journée, il est possible de travailler sur plusieurs Work Items en même temps. De ce fait, je recommande de faire cette saisie des temps chaque jour (en fin de journée). Cela évite, une fois en fin de semaine, d’avoir oublié combien de temps on a pu passer sur une dizaine de Work Items différents !
Partagez:

Team Foundation Service

Avec l’arrivée de la version 2012 de Team Foundation Server, Microsoft a développé la version « cloud » de TFS intitulée Team Foundation Service.

J’ai essayé ce service durant quelques jours, et voici les points intéressants que j’ai pu relever :

  • L’utilisation de ce service est gratuite, mais limitée à 5 utilisateurs ;
  • C’est un service dans le cloud, donc accessible depuis n’importe quel poste connecté à Internet ;
  • Possibilité de se connecter facilement depuis Visual Studio ;
  • On retrouve les fonctionnalités clés : Source Control, Work Items, Team collaboration, Build, Testing, Deployement…
  • Axé agilité, avec différents templates disponibles pour les projets (SCRUM, Agile, CMMI …) ;
  • Fonctionnalité de « chat-room » par projets pour discuter avec les différents membres de l’équipe ;

Source : http://tfs.visualstudio.com/en-us/feature-tour

Partagez:

Extension Visual Studio devColor

Une extension Visual Studio 2010 bien utile, permettant d’avoir dans son code un aperçu des couleurs (notamment en CSS), selon le code hexadécimal saisi.

devColor

A télécharger ici : http://visualstudiogallery.msdn.microsoft.com/7dbae8b3-5812-490e-913e-7bfe17f47f1d

Partagez:

[EF4] Les types complexes

Définition

Tout d’abord, une petite définition de ce qu’est un type complexe dans Entity Framework :

Un type complexe est un ensemble de propriétés que vous pouvez regrouper. Parfois, votre code devient plus clair lorsque vous regrouper les propriétés. Nous allons ici montrer comment vous pouvez créer des types complexes à partir du designer.

Avant la version 4 de Entity Framework, vous pouviez aussi créer ces types complexes. L’inconvénient était que vous deviez le faire manuellement, ce qui signifiait que vous deviez vous rendre dans le CSDL (schéma conceptuel) et ajouter le code XML nécessaire pour créer le type complexe. Le problème avec ceci est que, une fois que vous avez créé votre type complexe, on ne pouvait plus ouvrir le designer de l’EDM, parce que celui-ci ne prenait pas en charge les types complexes.

Exemple d’utilisation

Car les exemples sont souvent plus parlants, nous allons ici étudier un cas concret de type complexe.

Prenons une entité « Customer » dans le designer de l’EDMX, ce client possède plusieurs propriétés, notamment celles concernant son adresse :

Ces différentes propriétés sont : Street, PostalCode, City, Country. Ce sont ces éléments que nous allons regrouper en type complexe.

Continuer la lecture de [EF4] Les types complexes

Partagez: