Conseils architecture : 1 framework d'entreprise pour plusieurs application web
Bonjour, nous essayons de créer un framework d'entreprise pour générer des sites ASP net :
chaque appli que l'on génère doit partager avec les autres les fonctionnalités suivantes :
- Charte graphique (on utilise des templates)
- Localisation
- Identification
Le problème que je rencontre vient du besoin d'avoir des templates de pages ayant des comportements commun : chaque nouveau module dans un site asp fonctionnera toujours ( à priori) sur le modèle suivant :
->1 page de listing affichant les données que l'on doit visualiser/modifier/supprimer
-> 1 page de modification accédée par la vue de listing (après une mdification il est possible de revenir au listing)
-> 1 page de création accédée par la vue de listing (après une création on est redirigé automatiquement vers le listing)
J'ai donc créer des classes de bases ayant les comportements décris dont les pages de mon site héritent mais j'ai peur d'avoir un framework trop figé...
Comment dois je m'y prendre ? Avez-vous des conseils ?
Existe-il des frameworks de ce types à votre connaissance ?
La création d'un Framework
La création d'un Framework est véritablement une excellente solution pour les bureaux d'études qui sont amenées à maintenir une grande variété d'applications.
Un Framework peut fédérer voir imposer le design des applications, le mode d'accès aux données, l'architecture d'accès aux données, l'architecture des services, les bonnes méthodes de développement qui seront appliquées,...
J'ai créé un certain nombre de Framework implémentant des architectures métier au cours des dernières années et cela pour différents clients. L'expérience que j'en retire est que c'est véritablement un choix qui permet de booster les capacités de développement de l'ensemble du bureau d'étude. Il faut cependant faire attention au moins aux points suivants :
- Un Framework doit être documenté plus que n'importe quel autre type de développement. C'est une grosse part du travail. J'utilise la vidéo pour présenter de multiples démonstrations afin de gagner du temps et d'en faire gagner.
- Un Framework doit avoir été réfléchis au sens large. Sinon, il sera trop rigide et donc très vite inutile.
- Un Framework doit être développé en respect de bonnes méthodes de travail. La connaissance des Designs Patterns s'avère très utile. Il est primordiale de bien penser à séparer totalement ses différentes couches, à ne pas les coupler les unes aux autres. Il faut toujours avoir à l'esprit la compatibilité ascendante.
- Un Framework doit simplifier la vie du développeur. Pour cela il est utile d'intégrer sont Framework via différents outils ou assistant au sein de Visual Studio. Cela implique des connaissances en ce qui concerne l'extensibilité de ce dernier. C'est un gros travail, qui ne peut se faire très souvent que lorsque le Framework est terminé. C'est à dire lorsque l'on a plus le temps...
Si je peux vous donner un conseil, ne vous découragez pas. C'est un excellent choix dont vous tirerez parti pendant de nombreuses années.
A la date d'aujourd'hui, compte tenu des différentes situations que j'ai rencontré, mon avis est que la meilleur solution c'est un Framework :
- Basé sur une architecture métier avec totale séparation des couches.
- Au sein duquel des automates produisent l'ensemble du code de base, comme les objets qui reflètent la structure des données
- Au sein duquel les objets peuvent être automatiquement exposés sous forme de services afin d'exposer le métier à d'autres applications
- Disposant de ses propres contrôles d'interface capables d'exploiter l'ensemble des avantages d'une telle architecture. La simple capacité de remonter des libellés automatiquement localisés (multilingue) d'une souplesse extraordinaire. Il est possible de créez des contrôle d'interface totalement WYSIWYG, avec différentes zones de saisie, des modèles, des tâches...
- Intégrant par défaut tous les mécanismes pour la localisation
- Disposant d'objets de stratégie
- Intégré à Visual Studio
