Conception d'une moulinette générant la couche entité et la couche Accès
Bonjour,
Je me suis mis à Visual Studio 2005 depuis cet été et je dois dire que je souffre beaucoup. Je viens du monde VB6 & SQL Server (Ado Oledb), et je n'y connaissais rien en programmation Objet et encore moins en développement WEB.
Je suis un informaticien indépendant (senior et dépassé), et j'ai eu beaucoup de mal à appréhender ce monde là : on ne parle pas le même langage. Je me suis auto formé et j'ai suivi une formation qui m'a quasiment coûté le tiers de mon dernier contrat.
Mon premier soucis avant d'attaquer le développement d'une application Web que j’ai vendue a été de reconstruire un atelier de génie logiciel qui me permette de retrouver un environnement familier, que je maîtrise et qui autorise des développements stables, fiables, et duplicables.
Dans un logiciel de gestion qu'il soit Web ou non, la base de données est la partie la plus importante. Comme mes progiciels VB6, sont hyper stables et suffisamment puissants pour ma clientèle, je n'ai pas voulu la reconcevoir.
Le challenge que je me suis fixé c'est que mes bases de données, puissent être attaquées par mes anciens progiciels VB6 et les applications Web Visual Studio 2005 que je dois écrire.
Ainsi je peux proposer un environnement mixte à mes clients Réseau et/ou Web.
Quand je me suis attaqué au problème, j'ai vite vu qu'il fallait adopter une architecture 3tiers et le DataBinding. Quand j'ai commencé à concevoir la couche métier, je me suis aperçu que la charge de travail était trop importante (plus de 300 tables, et dont certaines sont dodues).
Je me suis mis à la recherche de générateurs (codesmith et autres) mais soit je n'y comprenais rien, soit le résultat était décevant.
En désespoir de cause (comme à l’ancienne) , je me suis mis à écrire un générateur de couche métier adapté à mes besoins.
Auparavant, suite à ma formation ASP Net, j'ai conçu un modèle avec quelques tables pour vérifier le fonctionnement de la couche métier avec le Databinding.
Ensuite j'ai utilisé VB.net (WinForm) pour développer la moulinette (ou le générateur si vous préférez).
Cela m’a pris plus d’un mois de travail (j’en ai profité aussi pour me former à VB.Net que je ne connaissais pas)
Que fait la moulinette :
1) Elle se connecte sur SQL 2000
2) On choisit une base de données
3) On choisit les tables ou les vues
4) On génère au choix :
a) les entités
b) la couche standard d'accés aux données (procédures standard CRUD avec ou sans transaction. Ce sont des classes partielles non modifiables par le programmeur) cette couche est en principe écrasée à chaque génération
c) la couche spécifique d'accès aux données (classes partielles modifiables par le développeur) cette couche n'est pas en principe écrasée à chaque génération
d) les procédures stockées à inclure dans SQL Server
Cette moulinette m'a permis de générer quelques 200.000 lignes de code propre et stable. Elle ne gère pas tous les questions, mais elle permet le DataBinding des GridView avec des collections (List of entites), le DataBinding des formview ou detailview avec des entités. Le problème du tri dans les gridview est résolu avec le SortExpression : on n’a pas besoin de passer par un DataSet.
Pour les jointures et les transactions il faut écrire un peu de code dans les procédures d'accès au données spécifiques (celles qui ne sont pas écrasées par une nouvelle génération).
L’intérêt de tout ceci est que la couche interface Utilisateur est indépendante de la couche métier, et je peux dire que lorsqu’on a fait cet énorme effort, c’est quand même beaucoup mieux.
PS: Pendant ces moments là on se sent un peu seul (techniquement parlant). aussi je suis prêt à partager cette technique, en échange d'indulgence sur le jugement de mon code et pourquoi pas le faire évoluer ensemble
Répondre avec citation
... mais qui me parait légérement effrayant au vu de mes délais 
(surtout que je travaille en TimeBoxing...).
Envoyé par Exsilius
)
). Faut dire que j'aime les classes bien typées, et surtout, qu'on le veuille ou non, le recours au CommandBuilder au moment du Runtime est à éviter le plus possible (pour des raisons de performance).
Partager