Suite de ma première note sur ce thème,
Part II : Utiliser du code SQL existant
La migration d'un parc applicatif vers du .Net peut se traduire pour certaines applications stratégiques par une réécriture complète de l'Ihm et de la couche métier.
Dans ce cas, bien réutiliser le code SQL (procédures stockées, fonctions), qui peut porter le coeur de métier, peut devenir un enjeux stratégique.
La réponse peut se trouver encore du côté de LinqToSql ou de l'entity Framework même si celui-ci n'est encore aussi abouti (Beta 3) et dans lequel on retrouve moins de possibilités aujourd'hui (tables, vues, proc).
Ces framework permettent un wrapping déclaratif entre l'applicatif (qui génère une fonction typée avec un nom anglais) et du code sql (une procédure stockée par exemple avec un nom français). Le développeur a ainsi accès à une méthode métier sans avoir à connaitre son implémentation SQL. Le mapping est alors fait dans la phase de conception avec le modeleur graphique.
Il ne s'agit pas ici de savoir s'il est plus intéressant d'avoir une procédure stockée ou bien une requête linq, on peut lire la note suivante sur ce sujet Maximilian Beller's Blog: Performance comparison between Linq, NHibernate and ADO.NET / Stored Procedures mais bien de réutiliser un existant.
L'idée est encore de bénéficier des apports d'un ORM sans s'y investir lourdement dans des contextes particuliers ou l'on a un existant à gérer.
Aucun commentaire:
Enregistrer un commentaire