Tout le mois de Décembre (et une bonne partie de Janvier), j’ai travaillé quasi-exclusivement sur un projet ou la DAL était générée avec des templates tt customisés de Subsonic 3.

Tout allait bien, la vie était belle, faire une nouvelle requête me prenait grosso modo 5 minutes, dans le genre :

   1: DataRepository<Customer>.GetAll()

   2:       .Where(customer => customer.fk_company == companyId)

Et tout ca avec possibilité d’injecter le Repository que je voulais en cas de test, et la certitude que je ne récupérerais que les données que je veux, sans me poser plus de questions (oui, dés que j’ai du temps, j’en dis plus, promis.).

Et la, du jour au lendemain, je reprends un projet qui suit le format « classique » des DAL basées sur des procédures stockées, avec une procédure stockée appelée par la couche DataAccess, elle-même appelée pa la couche Business, elle-même appelée par la couche Web.trois classes pour un appel à la base, avec, au final, moins de découplage et le même niveau de performances.

Je ne l’ai pas beaucoup exprimé auparavant, et c’est un avis à moi que j’ai, mais utiliser des procédures stockées pour faire des opérations CRUD est, pour moi, devenu un anti-pattern.

Les remarques habituelles de performances sont valables pour des procédures stockées complexes, mais, sur un projet ou 80% des procédures stockées sont des opérations mono-tables, elles n’ajoutent, à mon avis, qu’une surcharge cognitive à l’application (ou est le bug ? dans la table, la procedure, la couche DAL, la couche Business, la couche Web, le framework ???)

Pour tous les prochains projets, la cible que je vais essayer d’atteindre, c’est du 95% de code ORM, et 5% de Procédures stockées pour les traitements lourds.

Et vous (enfin, toi, mon unique lecteur :D), qu’en pensez-vous ? Utilisez-vous encore des procédures stockées ? Sont-elles un mal nécessaire, une aberration antédiluvienne, ou la seule raison pour laquelle vous vous levez le matin ?

Apres pas mal de transpiration (premières lignes écrites en Décembre), voila un tutoriel sur l’utilisation de base de SubSonic (SubSonic, c’est bon, mangez-en )

L’article est présent ici :

http://philippe.developpez.com/articles/Subsonic/

Le bon coté,  c’est que maintenant que l’article est publie, je vais pouvoir parler un peu plus de SubSonic sur ce blog (avant, je n’avais pas de référence en français a fournir )

Maintenant, allez télécharger SubSonic, et commencez a travailler avec une DAL propre et facile a utiliser en moins de temps qu’il ne vous en a fallu pour lire ce post…

En effet, comme je le montrais (et si vous n’avez pas lu l’article, allez-y maintenant ), SubSonic peut se révéler très puissant pour travailler avec des opérations de type CRUD, ainsi que pour le mapping des objets de la base de données avec les objets .net, mais qu’en est-il des requêtes « tordues » ou « bizarres » avec lesquelles on est régulièrement forcé de travailler (et je ne vous parle pas des requêtes dont on hérite avec la maintenance d’une application vieille de quelques années :-/.) ?

Est-ce que je ne vais pas avoir aussi vite fait de tout me taper à la main ?

Dans les versions précédentes, on avait grosso modo deux choix :

1. Créer une vue ou une procédure stockée (en fonction de l’action), et appeler la vue ou l’action à partir de SubSonic
2. Avoir un moyen annexe pour « shooter » des requêtes directement dans la base (oui, un bon vieux select, avec un datareader, des dataset, des connections, t tout le toutim.)

Depuis la version 2, on à enfin un nouveau choix, plus « propre », et surtout plus rapide à mettre en ouvre, vous l’aurez deviné, l’objet InlineQuery.

En terme de code, il suffit de faire :

(Ceci est évidemment un exemple simpliste, mais c’est pour donner une idée).

Dans l’exemple du dessus, le @surname va permettre à SubSonic de créer une requête paramétrée directement. Si on avait voulu ajouter plus de paramètres, la fonction attends un tableau d’objets, on peut donc se lâcher ;).

InlineQuery propose aussi des méthodes renvoyant des DataReader, des DataSets, des scalaires (wow, un ExecuteScalar<T> ), et même un ExecuteTypedList, pour renvoyer une liste de T.

Voila, facile, pas cher, que du bonheur

Du coup, je me suis installé SQLite sur ma machine a la maison, téléchargé le provider SQLite pour ADO.NET, et en…trois minutes, j’ai ma base en route.

Je ne connaissais pas du tout SQLite, mais cette base de données me botte…

Une dll a ajouter au projet web, un fichier db3, et on a une petite base de données relationnelles légère, suffisamment réactive pour des petits volumes, et qui se sauvegarde en copiant le fichier db3…Que du bonheur, quoi

Pour les pré-requis:

• ADO.NET 2.0 SQLite Data Provider
• Subsonic
• …et c’est tout…

Pour une comparaison entre MySQL, PostgreSQL et SQLite, voir ici:

http://www.sqlite.org/speed.html

Apres de longs mois d’attente (pour moi), la version 3 de mon outil chouchou sort enfin

Au programme de la version 3:

• un moteur Linq qui permets d’utiliser Subsonic « à la » Linq to Sql (mais avec toutes les table supportées, Oracle, SQLite, et compagnie)
• un système de templates basés sur les templates T4, ce qui les rends faciles à customiser ou à faire évoluer
• une tonne de tutoriels (la version précédente en manquait cruellement), disponibles ici
• un nouveau système de Repository, qui, couplé aux migrations, permets entre autres une approche beaucoup plus « POCO », et même de générer la base de données automatiquement depuis le code !

Forcément, cette version nécessite le Framework 3.5, ca tombe bien, mon client vient de passer à Visual Studio 2005 ;).

Le lien pour télécharger la bête est là :

http://subsonicproject.com/Download

.et je comptes bien en reparler