[Architecture] LINQ et le développement en couche
Voici un email que j'ai reçu au début de la semaine dernière:
Etant novice dans le .Net (avec un interet particulier sur les nouveaux framework 3.0 et 3.5) et desireux de pouvoir créer des applications/sites web avec une bonne architecture, J'ai lu votre articles [.NET] Article d'introduction au développement en couches que j'ai trouvé très interessant!
Seulement voila, avec l'apparision de LINQ, j'aimerai savoir comment va évoluer cette architecture?
Avec l'arrivée de plus en plus pressante de LINQ, je me suis dit qu'il s'agissait du genre de questions qui allaient rapidement faire leur apparition: c'est pourquoi je vous fait partager la réponse que j'ai envoyé (et qui n'engage que moi).
Lorsque l'on développement une application, on essaye au maximum d'isoler les différentes couches dans différents projets (comme expliqué dans mon article):
- Une couche pour l'interface graphique (GUI)
- Une couche pour la manipulation des règles et objets métier (BLL)
- Une couche pour l'accès aux données (DAL)
- Etc....
L'apparition de LINQ est un atout majeur en terme de développement d'applications. Cependant, il convient de bien distinguer LINQ To SQL du reste (LINQ To Objects, LINQ To XML, etc...).
En effet, LINQ To SQL est utilisé pour manipuler la base de données: création d'éléments, mise à jour d'une table, etc... Ce n'est pas parce qu'il s'agit d'une nouveauté que les méthodes utilisées actuellement vont devoir changer ! Actuellement, dans votre couche d'accès aux données, vous utiliser sans doute des objets tels que DBConnection, DBCommand, etc.... et bien LINQ To SQL ne va, en rien, modifier votre façon de travailler: vous continuerez de développer vos couches d'accès aux données mais en utilisant les "nouveautés" apportées par LINQ To SQL: DataContext, Mapping Objet/Relationnel, etc... Dans une version V1 d'un projet, vous avez créer votre DAL vous-même, en définissant vos objets métier ? Dans la V2, la DAL (et les objets métier) pourront être générés automatiquement avec LINQ To SQL, au moyen d'un simple glisser/déposer dans Visual Studio.
(Il est à noter qu'un tel discours pourrait également être appliqué à LINQ To Datasets et LINQ To Entities)
En ce qui concerne LINQ To Objects (et LINQ To XML d'ailleurs), la réponse est similaire: votre couche métier pourra facilement être réécrite en utilisant cette nouvelle fonctionnalité (ou simplement en utiliser quelques morceaux) mais il faut bien garder 2 choses en tête:
- Rien ne vous obligera à le faire: votre BLL fonctionnait très bien avant alors pourquoi vouloir la changer
- Si vous le faîtes, vous vous rendrez vraiment compte à quel point utiliser LINQ, dans vos développements, vous permettra de gagner du temps et pourra, éventuellement, rendre votre code plus.... sympathique à lire pour les développeurs qui vous succèderont
Pour conclure, je ne dirais qu'une chose: Oui, LINQ est une technologie vraiment puissante qui permet de faire plus vite et mieux mais Non, cela ne changera en rien la façon de concevoir des applications: à partir du moment où l'on utilise une base de données, on aura toujours besoin d'une DAL (couche d'accès aux données), que celle-ci soit écrite à la main, via des générateurs de code ou avec LINQ
My 0.02 cents
A+
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
