Comme vu précédemment, cinq langages de développement sont nécessaires au développement d’une application Web .Net.
Visual Studio architecture le code en 2 conteneurs logiques : - un premier niveau de séparation nommé « solutions » - une solution contient des « projets »
Un « projet » .Net contient le code applicatif et se caractérise par une technologie : Visual Basic, C, C++, C#, F#, MVC, Framework, Reports, Base de données, etc…. Dans le présent document, seuls les projets de type MVC, Framework et Reports et Base de données sont abordés.
3 Contrairement à ce que son nom pourrait laisser penser, le langage C# ressemble globalement plus au Java qu'au C ou au C++.
4.1.1 Le s s o lu tio n s
Programmer une application en plusieurs « solutions » apporte des avantages sur le plan de la compréhension logique du développement, de la maintenance, de l’évolutivité et du travail collaboratif :
- Compréhension logique du développement : Chaque application représente un découpage fin du développement global, par besoin technico-fonctionnel.
- Maintenance et évolutivité : Un accès réduit à une solution permet de réduire la complexité dans la compréhension du rôle de chaque projet, de mieux cibler les projets et instructions de code à corriger ou à faire évoluer.
- Travail collaboratif : L’équipe de développement pourra se voir attribuer une solution, permettant d’avoir un rôle clair sur les tâches de développement et évitant ainsi les gestions complexes de conflits dans le code. Moins de surveillance sur les actions d’archivage et d’extraction. Navigation entre les projets facilitée.
Les compilations et les kits de déploiement sont gérés au niveau des « solutions ».
Nous recommandons de mettre en place plusieurs solutions pour des applications d’une taille importante, à partir de 8 projets.
Dans la majorité des cas, les applications seront développées à l’intérieur d’une seule solution.
Dans le cas d’un développement multi solutions, nous recommandons :
- de créer une solution globale afin de réaliser des tests de cohérence et de compilation - de faire valider le découpage « solutions » par le chef de projet Client
4.1.2 Le s p ro je ts
Pour une solution donnée, nous vous recommandons de respecter le découpage suivant :
Fig. 11 – L’organisation des projets (exemple du projet SqueletteWeb)
On remarquera que chaque projet est matérialisé par une icône représentant la technologie associée.
Cette organisation du code d’une solution a fait l’objet d’un travail de réflexion important et s’appuie sur de nombreux retours d’expérience.
L’organisation de l’arborescence proposée ci-dessous a été conçue afin que le nombre de fichiers sous chaque branche soit le plus petit possible, ce qui rend globalement la solution Visual Studio très lisible, donc plus facile à maintenir.
Nous vous proposons un premier niveau de séparation par répertoire nommés « lib », « src » et « tests ». L’idée est d’isoler efficacement chaque partie et de faciliter l’accès lors des phases de développement. En effet, l’accès aux librairies est rare.
Le répertoire « src » contient les projets MVC, SQL et Reporting Services. Nous recommandons de séparer MC et V du modèle MVC qui isole le code lié aux données d’une part, et la préparation du code HTML d’autre part.
Remarque : la norme SQL CEA imposant de coder les règles de gestion métier dans les procédures stockées SQL, la partie Controller contiendra essentiellement des tests de redirection et d’erreur liés aux flux de données reçus.
A noter que la duplication d’une même librairie dans plusieurs projets d’une solution n’a aucun impact sur la performance de l’application. En effet, à l’exécution, IIS reconnait les librairies identiques et ne les charge qu’une seule fois en mémoire (cf. gestion du Global Assembly Cache4).
4.1.2.1 Le projet SQL
Fig 12 - Détail du projet Sql 4.1.2.2 Le projet BusinessLogic
Fig 13 – Détail du projet .BusinessLogic
4 http://msdn.microsoft.com/fr-fr/library/51ket42z%28v=vs.90%29.aspx
4.1.2.3 Le projet .Reports
Fig 14 – Détail du sous-répertoire .Reports 4.1.2.4 Le projet .Web
Fig 15 – Détail du sous-répertoire .Web 4.1.2.5 Le projet .Tests
On reprendra les mêmes arborescences que le projet testé. A savoir, le sous répertoire .BusinessLogic pour la partie métier, et le sous-répertoire .Web pour la navigation.
4.1.2.6 Le projet SQL
Le fait d’avoir un moteur SQL en local permet de résoudre toutes les différences de comportement entre le code c# et le code SQL. Le moteur localdb est le pendant du moteur IIS Express.
Grâce au projet « Base de données » inclus dans la norme, la gestion du versionning du code SQL s’effectue via le gestionnaire de sources de la même façon que le reste du code applicatif.
L’outil « SQL Server Management Studio » est déconseillée pour le développement courant.
« SQL Server Management Studio » ne doit être utilisé que pour des fonctionnalités autres que le développement : notamment l’administration et les performances.
4.1.3 Co n ve n tio n s d e n o m m a g e d e s s o lu tio n s /p ro je ts
Le nom d’un projet conditionne directement le nom des dlls.
Afin de repérer facilement les dlls sur un serveur d’application, nous recommandons la convention de nommage suivante :
- 1er mot : l’entité juridique qui est propriétaire du code de la solution
- 2ème mot : un critère de regroupement d’applications qui permet de classer les applications à l’intérieur de l’entité juridique
- 3ème mot : le nom de l’application fonctionnelle
- 4ème mot : le nom du module de l’application fonctionnelle.
Les mots sont séparés par des points « . ».
La longueur des mots sera la plus courte possible. Dans la mesure du possible, essayer de ne pas dépasser 12 caractères par mot.
Cea.Normanet.Autorisations.Formulaires Cea.Normanet.Autorisations.Reports Microsoft.Office.Interop.Word Microsoft.VisualStudio.Shell.Design
Fig 16 – Exemples de noms normalisés de solutions
4.1.4 Ge s tio n d e s lib ra irie s
Fig 17 – Accès aux librairies normalisées et autres
L’accès aux librairies s’effectue au travers des NuGets (natifs dans l’environnement VisualStudio à partir de la version 2012).
Les librairies CEA MVC sont livrées sous forme de NuGet.
La gestion des librairies non packagée NuGet s’effectue dans le répertoire « lib ». Si vous n’avez pas ce type de librairies, ne créer pas ce répertoire.
Dans les deux cas, les librairies font partie de la solution par défaut. Ces librairies n’étant du code « métier » de l’application, nous vous recommandons de déployer le répertoire « package » dans un répertoire partagé de votre environnement de développement. Ainsi, tous les développeurs intégreront les librairies en 1 clic dans leur projet Visual Studio.
Nous recommandons également d’isoler les librairies Javascript ainsi que les composants de la charte graphie (images, css, etc…). Dans le même esprit, ces composants ne font pas partie du code « métier » de l’application.
4.1.5 Le te m p la te CEA
Nous délivrons un template de projet NormaNet que nous vous conseillons d’utiliser. Ce template installe :
- les bibliothèques utiles et normalisés (inclus Jquery, ReportingServices, Kendo, …) - les répertoires permettant de respecter la norme MVC
- les exemples de codage pour les principales fonctionnalités