A-t-on besoin d’une Business Layer avec Entity Framework ? (1)

A-t-on besoin d’une Business Layer avec Entity Framework ?

Sommaire : Partie 1 – Partie 2 – Partie 3 – Partie 4

Pas nécessairement. D’une part, il parait important de ne pas systématiquement vouloir tout développer avec une architecture en couches. Nous n’avons pas tous besoin d’une UI, d’une Business Layer (attaquée éventuellement via une couche de services) et d’une couche d’accès aux données séparées et isolées. Il existe d’ailleurs d’autres solutions. Il est parfaitement possible de coder très proprement une application dans un seul et même projet Visual Studio. Le sage Rui Carvalho l’avait fait d’ailleurs remarquer très pertinemment lors d’une session Alt.NET. L’important est d’appliquer les principes SOLID… et que les namespaces reflètent ces principes. Si ces deux prérequis sont validés, il sera dans le futur très facile de déporter vos classes dans des projets dédiés. D’autre part, Entity Framework embarque déjà une bonne partie des comportements attendus d’une Business Library.

Qu’est-ce qu’une Business Layer ?

Revenons rapidement sur ce qu’est une Business Layer (que l’on nommera désormais BL par pure fainéantise) (aussi appelée Domain Logic, ou couche métier, mais peu importe son nom). Une BL contient la logique métier de l’application. Elle sert principalement à exposer une API utilisée par la couche de présentation et à prendre à sa charge l’ensemble de l’intelligence fonctionnelle de l’application. Le reste n’est (théoriquement) que présentation et bootstrapping. Elle doit donc dialoguer avec la couche d’accès aux données (la DAL, ou Data Access Layer) afin de déclencher toutes les opérations en rapport avec la persistance des données.

Et Entity Framework dans tout ça ?

Maintenant venons-en au fait. Entity Framework peut parfaitement servir de BL (et évidemment de DAL) :

• Elle expose une API claire, documentée, pérenne et simple à utiliser depuis la couche de présentation (ce qui peut déjà être un critère d’éligibilité en soi)
• La classe DbContext implemente le pattern Unit of Work : tout ce qui se passe entre l’instanciation de l’objet et l’appel à SaveChanges() se déroule dans une seule et même transaction. Cela permet d’effectuer des opérations complexes et cohérentes entre elles facilement.
• La classe DbSet<T>, où T est une entité métier, implémenter le pattern Repository. On y retrouvera donc toutes les méthodes CRUD permettant de manipuler aisément les données de la base et les traitements effectués dessus dans l’application.

Nous pourrions donc parfaitement nous contenter de ces points. C’est même déjà pas mal. D’ailleurs, le scaffolding MVC permet de générer des pages web dont le modèle implémente directement Entity Framework. Pour de petits projets, des POCs, des choses temporaires, ça se justifie parfaitement.

Très bien, mais du coup, Business Layer ou pas Business Layer ?

Deux inconvénients majeurs apparaissent :

• L’application est pieds et poings liés à Entity Framework. Ça peut être un point discriminant. Ou non. Dans les faits, les applications qui changent d’ORM relèvent plus de la légende urbaine que d’une réalité tangible. Mais il paraît toutefois plus sage (si ce n’est pas trop coûteux) de ne pas lier trop fortement l’intelligence applicative à la persistance des données.
• Et surtout : l’application devient difficilement testable. Lorsque nous testons une BL, nous cherchons à tester le bon comportement de l’application. Nous souhaitons savoir si elle se comporte conformément aux attentes de nos utilisateurs. Et dans ce cas, nous sommes obligés d’avoir une base de données à disposition pour jouer nos tests unitaires. Devoir se préoccuper de la persistance des données est une difficulté dont on aimerait pouvoir se passer.

Tout ceci pour dire que : une BL, ça peut être bien. Mais comme nous n’aimons pas réinventer la roue, et qu’Entity Framework a déjà tout un tas de choses prêtes à l’usage, nous allons voir dans les articles qui vont suivre comment développer une BL la plus simple et légère possible.