Qu’est-ce qu’un POCO ?

Définition

POCO signifie « Plain Old CLR Objet ». Un POCO représente un objet métier. Ce sont aussi ce que l’on appelle les entités d’un Domaine.

Celui-ci dispose de données et de toute autre logique métier que vous voulez y mettre. Dans Entity Framework ces entités sont automatiquement générées pour vous.

Sympa non ? Cependant, ces entités sont entrecoupées de fonctionnalités d’accès à la base de données qui vont clairement à l’encontre du SOC (Séparation des concepts). Les POCO sont des entités simples sans aucune fonctionnalité d’accès aux données, mais elles offrent toutes les fonctionnalités de EntityObject.

Attention : les POCO ne sont pas des DTO ! La différence : un POCO décrit une approche de la programmation (bonne pratique orientée objet), tandis que le DTO est un modèle qui est utilisé pour « transférer des données » en utilisant des objets.

Pour aller plus loin : https://msdn.microsoft.com/en-us/library/dd456853(v=vs.110).aspx

Partagez:

[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:

SQL Server : concatener des lignes avec STUFF

Sur un des projets sur lequel j’ai travaillé, un des besoins était de concaténer des informations présentes sur plusieurs lignes en une ligne avec un dénominateur commun.
Ce traitement était uniquement possible côté SQL, étant donné que le résultat de cette requête était directement affiché, sans traitement préalable possible. Sinon, dans la plupart des cas, j’aurai fait ce traitement dans le code dans la partie Business de l’application.

Exemple

Prenons les tables suivantes, l’une liste des départements, l’autre liste des villes dont chacune est liée à un département (relation 1-n)

SQLStuff01

 

Dans ma requête, je veux pouvoir concaténer sur une même ligne, l’ensemble des villes d’un département donné (le dénominateur commun).
Le résultat de la requête doit nous donner le résultat suivant :

SQLStuff02

 

Voici donc la requête à exécuter, avec la fonction STUFF :

SQLStuff03

 

Encore une fois, j’ai utilisé cette requête dans un cas d’affichage bien précis! A mes yeux ce n’est pas la meilleure des pratiques, c’est un traitement que l’on devrait pouvoir faire plutôt dans la partie code. Néanmoins on peut utiliser ce type de requête dans une View SQL et l’appeler directement par exemple dans un rapport SSRS…

Partagez:

AngularJS : architecture et bonnes pratiques

Un document que je ne saurai trop recommander pour les développeurs désireux de connaitre les bonnes pratiques sous AngularJS : https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/

C’est rempli de bonnes idées pour présenter sa solution, ainsi que sur les bonnes pratiques comme le nommage etc.

Architecture par fichier, répertoire ou bien modulaire ?

On a souvent l’habitude de voir des exemples d’applications AngularJS qui sont architecturés par ce que l’on appelle le « file pattern »:

AngularArchi02

 

L’ensemble des contrôleurs directives, services etc sont regroupés dans des fichiers.

Le problème avec cette approche, c’est qu’en terme d’évolution, on pourra vite se trouver avec des fichiers JS de taille importante… Imaginez que l’on ai une vingtaine de directives dans un même fichier ! Pour retrouver une directive spécifique il faudra prendre du temps pour scroller et la chercher…

Afin d’éviter cela, on préférera une architecture modulaire ou par features. Dans laquelle un ensemble de contrôleurs vues, services et directives seront répertoriées.

AngularArchi01
Dans cet exemple nous avons deux modules « bar » et « foo » qui ont des services et directives distincts. On préconise en général : 1 controlleur = 1 fichier .js etc
L’idéal ensuite est de créer un répertoire dans chaque module par type (Filters, Controllers, Directives, Partials etc.) afin d’avoir un classement des fichiers clair et lisible.

Il existe une démo qui applique de façon correcte ce pattern : https://github.com/angular-app/angular-app

Partagez: