Commissariat à l’énergie atomique
Centre de Saclay – 91191 Gif-sur-Yvette Cedex Tél. : 33 – 1 69 08 96 03 - Fax : 33 – 1 69 08 68 11
S ys t è m e d ’ I n f o r m a t i o n
NormaNet
DSI/ARCHI
G S I / D S I / AR C H I
Si g n a t u r e s
H i s t o r i q u e d e s v e r s i o n s
D o c u m e n t s d e r é f é r e n c e
V e r s i o n R é d a c t e u r s V é r i f i c a t e u r ( s ) E m e t t e u r ( s ) S t a t u t
V 1.3 D. POULAIN CEA
S. ROCHE SOPRA
L. ARRIVET CEA/DSI
VALIDE
Version Date Nature de l’évolution Pages
1.0 19/12/2014 Création
1.1 15/06/2015 Compléments gestionnaire de source 12
1.2 15/04/2016 Intégration API Zed! Prim’X 33
1.3 15/06/2018 Suppression de la bibliothèque MVC Contrib,
Recommandation Kendo UI pour les exports de données simples Préconisation Powershell pour le déploiement SQL
14 25 34
Nom Libellé
CEA_Normes SQL 2.0.pdf Normes de développement CEA SQL Server
http://msdn.microsoft.com/en-us/library/seyhszts.aspx Practices de gestion des exceptions
https://github.com/Microsoft/sql-server- samples/releases/tag/adventureworks
Base de données de référence proposé par Microsoft
http://www.asp.net/mvc/overview Site du Framework ASP.NET MVC.
https://blogs.msdn.microsoft.com/dotnet/2015/08/21/the- future-of-unity/
Modèle and practices Microsoft
Sommaire
1 PRESENTATION ... 4
2 ARCHITECTURE GENERALE ... 6
2.1 L’ARCHITECTURE INFRA... 6
2.2 L’ARCHITECTURE APPLICATIVE ... 6
2.2.1 Les outils livrés avec la norme ... 7
2.2.2 Les recommandations de développement du code ... 8
3 LA PLATEFORME .NET ... 10
3.1 L’ENVIRONNEMENT DE DEVELOPPEMENT ... 10
3.1.1 Visual Studio Professional ... 10
3.1.2 GitHub / Team Foundation ... 11
3.1.3 Visual Studio Enterprise ... 11
3.1.4 Configurations de l’environnement de développement ... 12
3.1.5 Synthèse des composants recommandés ... 13
3.2 LES PLATEFORMES DE DEPLOIEMENT ... 14
4 LES NORMES DE DEVELOPPEMENT ... 16
4.1 L’ORGANISATION DU CODE ... 16
4.1.1 Les solutions ... 17
4.1.2 Les projets ... 17
4.1.3 Conventions de nommage des solutions/projets ... 19
4.1.4 Gestion des librairies ... 20
4.1.5 Le template CEA ... 20
4.2 L’IMPLEMENTATION DU CODE ... 21
4.2.1 L’authentification ... 21
4.2.2 Les autorisations (rôles, profils et périmètres) ... 21
4.2.3 Les paramètres ... 21
4.2.4 Le dialogue avec SQL Server ... 23
4.2.5 La pagination et les listes longues ... 23
4.2.6 Les conventions de nommage des objets ... 23
4.2.7 Les recommandations de codage MVC ... 24
4.2.8 Javascript / Jquery / Ajax ... 25
4.2.9 Les inversions de contrôle (MicroSoft Unity) ... 25
4.2.10 Les exports de données ... 25
4.2.11 Les éditions ... 26
4.2.12 Les graphiques ... 27
4.2.13 L’ergonomie... 28
4.2.14 Les tests unitaires ... 28
4.2.15 Les tests de qualité de code ... 29
4.2.16 Les batchs ... 29
4.2.17 Le chiffrement... 30
4.2.18 Messages d’erreurs ... 30
4.3 LES TEMPS DE REPONSE ... 31
4.3.1 Pendant le développement ... 31
4.3.2 Après le développement ... 31
4.4 CONSTITUTION DU PACKAGE ... 32
5 L’EXPLOITATION ... 34
5.1 LE DEPLOIEMENT ... 34
5.1.1 Constitution du package ... 34
6 ANNEXES ... 35
6.1 ARCHITECTURE .NET MVC ... 35
6.2 TEAM FOUNDATION SERVER ... 36
6.3 QUELQUES BONNES PRATIQUES .NET ... 37
6.3.1 Authentifications ... 37
6.3.2 Connection SQL Server ... 37
6.3.3 Profils et rôles ... 37
6.3.4 Les logs ... 38
6.3.5 Les exceptions ... 39
6.3.6 Les données persistantes (cache, session) ... 41
1 PRESENTATION
Ce document s’adresse à la filière informatique du CEA1 et à tous les prestataires informatiques du CEA.
Il est cependant applicable sur toute plateforme .Net, même en dehors du CEA.
Contexte
En 1992, le CEA a été pionnier du développement Client /Server avec notamment l’application « ComDec » (Commandes décentralisées), déployée auprès de plus de 1000 utilisateurs. A cette occasion, la Direction de l’Informatique du CEA avait émis une norme de développement Client / Serveur « Normacs » et un outil de gestion des habilitations « Habilita » qui ont été repris par la filière informatique CEA en apportant un gain significatif aux applications locales des unités.
En 2003, afin de gérer les développements Web, la DSI a créé la norme « Enormacs », basée sur le langage Java et le référentiel J2E. Cette norme a fait évoluer les outils « Habilita » existants, en intégrant notamment le portail de gestion « EspaceSigma » et un annuaire LDAP dédié. De fait, cette norme n’était pas compatible avec les développements des unités du CEA.
En 2013, le CEA fait le choix de déployer une plateforme nationale SharePoint pour ses besoins collaboratifs et de déploiement de site Web. D’autre part, les besoins d’interopérabilité entre les applications de gestion et la bureautique se multiplient. Ces évènements ont provoqué le besoin de refondre les normes de développements des applications Web au CEA et de les rendre à nouveau compatible avec les développements des unités.
Objectifs
Les objectifs stratégiques de la présente norme sont triples :
- harmoniser les développements spécifiques Web du CEA : les entités centrales et locales pourront développer des applications de la même façon en utilisant les mêmes outils.
- créer des passerelles technologiques entre les applications Web et la bureautique (via l’utilisation de la plateforme .Net et les outils MS Office)
- créer des passerelles technologiques entre les applications Web et la plateforme SharePoint (via l’utilisation de la plateforme .Net et les outils SharePoint)
Fig 1 – Intégration .Net dans le système d’information
1 Civil + Militaire
Par ailleurs, cette norme intègre les objectifs classiques d’industrialisation des développements :
- diminuer significativement les coûts de maintenance - garantir des bons temps de réponses.
- garantir la qualité des déploiements
Enfin, nous avons veillez à ce que la mise en place des normes de développements .Net CEA n’exige pas de modifications techniques des installations existantes. Autrement dit, une application normalisée ne nécessitera pas de coûts supplémentaires d’infrastructure et pourra cohabiter avec d’autres applications .Net sur une même plateforme.
Enjeux
Nous espérons que vous utiliserez cette norme pour améliorer la qualité de vos développements Web et participer à l’urbanisation du système d’information du CEA.
2 ARCHITECTURE GENERALE
2 . 1 L’AR C HITE C TUR E INF R A
La présente norme a été conçue pour un déploiement type intranet. A ce titre, les contraintes de sécurité liées au déploiement internet ne sont pas abordées (notamment le cryptage des flux et les intrusions via javascript). Dans le même esprit, la norme ne traite pas l’externalisation sur le Cloud.
Chaque plateforme .Net possède son moteur SQL Server, ainsi que son ou ses serveur(s) d’application IIS. Nous recommandons fortement l’utilisateur de l’annuaire Active Directory Central et l’utilisation du protocole d’authentification Kerberos. En effet, ce type d’authentification :
- évite aux utilisateurs la saisie de leurs identifiants
- évite le maintien de comptes utilisateurs dédiés aux applications - est natif sur les plateformes .Net
Fig. 2 - Les applications Web.Net sur le réseau CEA Net
2 . 2 L’AR C HITE C TUR E AP P LIC ATIVE
Les choix d’outils et de librairies ont été guidés par le souci de pérennité. A cet égard, nous avons donné une priorité aux composants Microsoft et, pour les composants opensource, vérifié leur utilisation massive.
D’un point de vue déploiement, adopter la norme .NET CEA consiste à ajouter les composants suivants sur une plateforme :
- Des fichiers exécutables sur le serveur .Net
- Une database CeaCentralAutorisations sur le serveur SQL Server
Ci-dessous, une plateforme .Net normalisée CEA.
Fig. 3 - Architecture générale d’une plateforme de production .Net normalisée
L’ajout des composants CEA est transparent pour l’application métier. Seules les procédures stockées SQL « métiers » effectuent une « jointure » avec la table CeaCentralAutorisations.dbo.UserPerimetre.
NormaNet gère deux authentifications : Active Directory (recommandé) et SQL Server.
En constatera ici, que l’adoption de la présente norme ne modifie pas une plateforme .Net existante : il s’agit d’installer des composants IIS et SQL Server supplémentaires.
2.2.1 Le s o u tils livré s a ve c la n o rm e
Le premier apport significatif de la norme CEA est l’apport de la gestion automatisée des autorisations et des paramètres applicatifs.
L’application Cea.Normanet.Autorisations
Publiée et maintenue par l’informatique centrale du CEA, l’application
« Cea.Normanet.Autorisations » gère automatiquement les autorisations (profil/périmètre) de n’importe quelle application .NET/SQLServer (script de création + composants C#/Asp)
- évite de redévelopper une application dédiée à la gestion des habilitations
- fonctionnent immédiatement sur n’importe quelle plateforme .Net/SQLServer (autonomes et indépendants de l’informatique centrale), avec ou sans AD
- est maintenue régulièrement par l’informatique centrale avec une compatibilité ascendante (assimilable à un progiciel).
L’application Cea.Normanet.Properties
Publiée et maintenue par l’informatique centrale du CEA, l’application métadonnées gère automatiquement les paramètres les plus courants d’une application.
Elle permet de paramétrer immédiatement tous les liens vers les fichiers d’aide, les images, etc… de toute application.
2.2.2 Le s re c o m m a n d a tio n s d e d é ve lo p p e m e n t d u c o d e
Le deuxième apport significatif de la présente norme concerne le développement du code.
Nos recommandations sont basées sur des retours d’expérience de maintenance applicative de plusieurs grands comptes.
Nous recommandons l’utilisation du modèle MVC en remplacement du modèle historique Web Forms. Le concept clé de MVC consiste à séparer le code en 3 parties dans le codage.
Fig 4 – L’approche MVC
C’est cette approche qui apporte la productivité (cf. § « Architecture .Net MVC » en annexe du présent document).
Notre norme est une base minimale pour développer une application Web professionnelle. A ce titre, nous avons volontairement pris le parti de proposer un niveau ergonomique faible des pages Web. Cela laisse une liberté pour ajouter des bibliothèques spécialisées en fonction de vos besoins.
Parmi les fonctionnalités les plus représentatives d’un développement Web, nous avons retenus les suivantes :
- bandeaux - barres de menu
- formulaires de recherche avec un tableau - formulaires de consultation/saisie
- éditions simples
- éditions avancées avec export Pdf, Word, Excel - graphes
- exports de données Csv - exports de données Excel - pagination de tableaux - tree views
Un templateVisual Studio est livré avec la norme.
Il doit être la base de tous développements NormaNet.
Le template contient des exemples de codage des fonctionnalités ci-dessus, mais également des commentaires expliquant les choix de codage et faisant référence au présent document.
Remarque : le développement des outils Cea.Normanet.Autorisations et Cea.Normanet.Properties est normalisé. Leurs sources sont également un excellent modèle.
L’application de cette norme demande une journée d’adaptation pour un développeur : prise de connaissance de l’arborescence des fichiers, de la table SQL UserPerimetre2 des profils et périmètre et de la librairie MVC.
Bien que l’apport de la norme soit très significatif en phase de maintenance, elle apporte également des résultats concrets en phase projet : tests unitaires et livraisons pour recette plus rapides et plus fiables.
L’application de cette norme apportera une dimension professionnelle à vos applications.
2 Equivalent table UTIAPP dans l’ancienne norme Normacs
3 LA P LATEFORME .NET
3 . 1 L’E NVIR O NNE ME NT DE DE VE LO P P E ME NT
L’objectif de ce paragraphe est de donner les critères de choix vous permettant de dimensionner au mieux vos postes et vos serveurs de développement en fonction de vos besoins. Tous les cas sont étudiés, de la plus petite à la plus grande configuration.
Un environnement de développement .Net est constitué de deux outils : - Visual Studio (VS)
- Un gestionnaire de source (GIT recommandé)
Le système d’information central du CEA n’offre pas de plateforme TFS.
L’accès à MSDN permet de bénéficier des avantages suivants : - Accès au support Microsoft,
- Accès prioritaire dans les forums MSDN,
- Ressources de développement Windows 8, Windows Phone et cloud Azure.
Nous recommandons d’installer tous les produits de développement en langue anglaise.
3.1.1 Vis u a l S tu d io P ro fe s s io n a l
Toutes les versions de Visual Studio incluent par défaut un serveur SQL Server « LocalDB ».
Dans tous les cas de figure, quel que soit le contexte de développement, nous recommandons d’utiliser le moteur SQL Server LocalDB comme base de données de développement pour chaque développeur.
Avantages d’une base SQL locale :
- suppression des serveurs SQL dédiés de développements : gain infogérance
- portabilité du développement dans les agences des sous-traitants : souplesse dans la gestion des contrats
- indépendance des traitements des autres développeurs : batchs lourd, ralentissements - Permet une réelle mesure de la performance avec SQL Profiler : facteur clé de succès
pour le déploiement. Lire attentivement le paragraphe « Performance » du document de normes SQL.
Inconvénients d’une base SQL locale
- initialiser la base de données locale en début de projet
- risque de décalage entre la version SQL Server locale et la version SQL Server de déploiement.
L’instance localdb est limitée à 10GOctets. Aussi, si cela n’est pas suffisant, nous vous conseillons d’installer une version SQL Server sur le PC de développement, plutôt que sur un serveur.
On notera que, depuis SQL Server 2008, les évolutions sur le langage SQL sont peu nombreuses entre versions. Dans la pratique, il est très rare d’être confronté à des incompatibilités de code SQL entre versions SQL Server.
Dans le cas d’une différence entre la version SQL Server de développement et production, nous recommandons de développer sur la base SQL Server locale et de valider les éventuelles anomalies SQL lors des premiers tests d’intégration.
3.1.2 GitHu b / Te a m Fo u n d a tio n
Dans un projet de développement, un gestionnaire de sources est indispensable, et il convient de le mutualiser pour tous les développements de l’entreprise. Ainsi, les développeurs n’ont qu’un seul gestionnaire de source en face d’eux.
Les gestionnaires de sources permettent d’archiver tout ou partie du code, pendant le développement et surtout pendant la maintenance post projet. L’outil de gestion de configuration permet :
- de restauration une ancienne version du code - de recompiler une ancienne version de code - de comparer des versions de code
- …
Couplé à Visual Studio, nous recommandons l’outil GIT.
A noter que GIT est livré en standard dans l’outil TFS de Microsoft, qui permet également les logiques de travail collaboratif, d’intégration continue et d’analyse de code. Ces modules de TFS ne sont pas abordés dans ce document, notamment :
- Collaboration et planification Agile (Agile Planning & Collaboration) - Gestion de cas de tests (Test Case Management)
- Création de rapports (Reporting)
TFS propose un gestionnaire de build permettant d’effectuer des compilations avancées, notamment multiplateforme. La présente norme étant conçue pour que le build natif de Visual Studio soit directement exploitable, l’utilisation du gestionnaire de build TFS est donc rare.
Le build d’une application NormaNet, généré depuis le poste du développeur, est opérationnel immédiatement après sa copie sur les plateformes de qualification et de production.
Il est important de pouvoir identifier en amont, les éléments qui ne sont pas éligibles au stockage dans le gestionnaire de source, afin d’éviter de surcharger celui-ci avec des éléments inutiles.
Par défaut, une liste d’éléments à exclure par défaut. Cette liste peut être enrichie au moment de l’archivage. La note ci-dessous désigne les éléments considérés comme inutiles dans le contrôleur de code source. Afin d’éviter leur stockage, utiliser l’action / balise « ignorer modèle ».
3.1.3 Vis u a l S tu d io En te rp ris e
La version VS « Enterprise » permet de créer des « tests web », « tests de charge » et de vérifier la « couverture de code ». Ceci est un point essentiel afin de garantir une qualité de code optimum.
La couverture de code
La « couverture de code » permet de garantir que les règles de code / normes de codage préalablement définies, sont bien respectées tout au long du processus de développement.
Les tests Web
Les « tests web » permettent de garantir la non régression de l’applicatif lors de modifications du code. La programmation des « tests Web / UI » peut être réalisée sur le poste de développement.
Les tests de charges
Les « tests de charges » permettent d’effectuer les premiers tests pour « stresser » le serveur, à savoir par exemple la simulation de 1000 utilisateurs simultanés afin de vérifier la performance du code et les ressources du serveur.
*.*~ *.dll *.pdb *.log *.suo \Debug \Release \Bin \TestResults \Logs *.user
*.gpstate thumbs.db *.Publish.xml *.vsmdi *.testrunconfig PageList.xml \bin
\obj *scc *.gpState *.FileList.txt *.FileListAbsolute.txt *.trc
3.1.4 Co n fig u ra tio n s d e l’e n viro n n e m e n t d e d é ve lo p p e m e n t
Le choix de la configuration de l’environnement de développement dépend du nombre d’applications et du nombre de développeurs.
Environnement de développement minimal
Fig 5 – Environnement de développement minimal La plus petite configuration est la suivante :
- 1 poste de travail avec Visual Studio (C#, ASP, Reporting Services) - 1 serveur GIT
Convient pour : - 1 application - 1 développeur
On installera « SQL Server Management Studio » sur le poste de développement, cf. §
« Déploiement » du présent document.
Si des tests de montée en charge s’avèrent nécessaire, utiliser une version Visual Studio Enterprise (payante).
Environnements de développement intermédiaires
Fig 6 – Exemple d’un environnement de développement intermédiaire
On installera « SQL Server Management Studio » sur le poste Enterprise, cf. § Constitution du package du présent document.
Environnement de développement maximal
La plus grande configuration (n applications, n développeurs) est la suivante : - n postes de travail avec VisualStudio Enterprise (pour tuning précis du code) - m postes de travail avec VisualStudio Professional
- 1 serveur Reporting Service - 1 serveur GIT
Avec n<<m
Fig 7 – Environnement de développement maximal Le nombre de poste de travail VS Enterprise dépend
- Équipe projet de 2 à 4 personnes : au moins un poste VS Enterprise - Équipe projet > à 5 personnes : entre 2 et 4 postes VS Enterprise
3.1.5 S yn th è s e d e s c o m p o s a n ts re c o m m a n d é s
Les versions des composants évoluant rapidement, les versions sont données à titre indicatif
Outils Versio
ns
Visual Studio 2017
SQL Server Reporting Services 2016 http://msdn.microsoft.com/fr-fr/library/ms159106.aspx Team Foundation Server 2018 http://msdn.microsoft.com/en-us/library/bb385832.aspx
Serveur IIS 8
Bibliothèques de développements
Microsoft Norme MVC 5 http://www.asp.net/mvc Microsoft Unity (inversion de
contrôle)
5.5.6 MicroSoft OpenXML (export Excel
simple)
2.8.1
AutoMapper 6.2.2 http://automapper.org/
Microsoft Entity Framework 6.2.0
Log4Net 2.0.8 http://logging.apache.org/log4net/
ASP Razor 3.2.3 http://www.asp.net/web-pages/tutorials/basics/2-
introduction-to-asp-net-web-programming-using-the-razor- syntax
Microsoft ReportViewer 12.0.2 http://msdn.microsoft.com/en-us/library/ms251671.aspx
Jquery 3.3.1 http://jquery.com/
Json 10.0.3 http://james.newtonking.com/json
Kendo UI (objets dynamiques) 2018.1 http://docs.telerik.com/kendo-ui/
Glimpse Mvc 5 1.5.3 http://getglimpse.com/
On remarquera que la majorité des bibliothèques sont gérées par Microsoft, exceptées : - AutoMapper,
- Log4net, - Kendo UI.
3.1.5.1 AutoMapper
Cette bibliothèque est gérée par la communauté GitHub.
AutoMapper permet d’associer les propriétés de 2 objets différents entre elles. Le mapping d’objets étant la base du fonctionnement de MVC, cette bibliothèque est indispensable.
3.1.5.2 Log4net
Cette bibliothèque est gérée par la communauté Apache sous licence open source Apache.
Standard de fait pour la gestion des logs.
3.1.5.3 Kendo UI
Cette bibliothèque est maintenue par la société Telerik.
Nous l’avons sélectionnée notamment pour apporter une réponse probante aux demandes d’interactivité avec les graphes. Cette bibliothèque est full HTML5 et possède des composants intéressants, notamment le treeview.
Kendo UI n’est pas gratuit. Les licences sont gérées par l’informatique centrale du CEA.
3 . 2 LE S P L ATE F O R ME S DE DE P LO IE ME NT
L’objectif de ce paragraphe est de donner une première approche de vos plateformes de production. Le dimensionnement final en nombre de serveurs, CPU, RAM et disque sera affiné selon vos besoins.
Plateforme de production minimale
Fig 8 – Plateforme de production minimale
Même dans le cas d’une configuration minimale, nous recommandons d’installer IIS et SQL Server sur deux serveurs différents.
Plateforme de production intermédiaire
Fig 9 – Plateforme de production intermédiaire
Plateforme de production maximale
Fig 10 – Plateforme de production maximale
Autres plateforme
Plusieurs plateformes de recette (qualification) / qualité / intégration (pré-production) peuvent être mise en place.
Les critères de choix de ces plateformes sont nombreux et dépassent le cadre de ce document. Nous vous invitons à consulter le lien suivant :
http://dltj.org/article/software-development-practice/
4 LES NORMES DE DEVELOP P EMENT
Adopter la norme .NET CEA consiste à développer le code de façon uniforme, à respecter les meilleures pratiques, tout en laissant la liberté de conception aux développeurs.
Pour répondre aux objectifs décrits précédemment, trois idées principales :
- libérer le développeur des développements récurrents afin qu’il ne se consacre qu’au code correspondant au métier de l’application qu’il développe/maintient
⇒ réutilisation systématique de l’application Autorisations
- utiliser un minimum de composants pour assurer la pérennité du développement
⇒ réutilisation maximale des outils normés, maintenus et pérennes.
- organiser « efficacement » le code métier développé afin de diminuer significativement le temps de prise en charge et de compréhension du code
Le CEA a repris la norme MVC Microsoft :
- l’authentification par défaut est Active Directory via Kerberos - la récupération et la validation des données sont codés en C#3
- l’intégration du code SQL dans Visual Studio (le code SQL est géré comme le code c# et s’intègre nativement à TFS)
- la mise en forme des pages est codée en Razor - l’interactivité est codée en JavaScript
- les éditions sont codées avec l’outil Reporting Services - les exports Excel réutilisent les bibliothèques Microsoft Le CEA a enrichi cette norme MVC comme suit :
- l’accès aux données et l’intelligence métier sont codés en SQL
- les autorisations (rôles et périmètres) sont gérées en SQL (cf. Application Cea.
Central.Autorisations)
- les paramètres d’« exploitation » sont externalisés (connections par défaut, sizing par défaut) dans des fichiers de configuration Windows, hors IIS (mise à jour par l’infogérance)
- les paramètres « clients » (nom des contacts, url d’aide en ligne, etc…) sont gérés en SQL (mise à jour directe sans déploiement, cf. application Cea.Normanet.Properties) - la gestion de la pagination est normalisée
- la gestion des graphes dynamiques est possible via une bibliothèque full HTML5
- les règles de convention de nommages des composants métiers (ex : Cea.Assainissement.ControleCommandes) sont normalisées
- le paramétrage du choix Authentification « AD Kerberos » ou « SQL Server » (développement de la fenêtre d’authentification SQL Server) est codé
- le code des Views est isolé dans un « projet » indépendant du code Model et Controller - le code Reporting Service est isolé dans un « projet » indépendant
- les appels des rapports ReportViewer (SSRS) sont améliorés - les ressources statiques sont isolées dans un site indépendant
Les normes de développement SQL font l’objet d’un document séparé (cf. § documents de référence) qu’il faut prendre en compte.
4 . 1 L’O R G ANIS ATIO N DU C O DE
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
4 . 2 L’IMP LE ME NT ATIO N DU C O DE 4.2.1 L’a u th e n tific a tio n
Nous recommandons de gérer l’accès au moteur SQL Server avec des comptes nominatifs et non un compte générique. De cette façon, tous les utilisateurs d’une application ont un login SQL Server et sont reconnus par la commande SQL s_username().
Nous recommandons l’utilisation des comptes Active Directory afin de bénéficier notamment : - de l’intégration avec l’authentification Windows
- des outils de gestion natifs : Active Directory Manager et Kerberos.
Si vous n’avez pas d’annuaire Active Directory, vous devez utiliser les comptes SQL Server.
Ne pas utiliser les comptes SQL Server lorsqu’un annuaire Active Directory est disponible.
4.2.2 Le s a u to ris a tio n s (rô le s , p ro fils e t p é rim è tre s )
Lorsque l’utilisateur est reconnu et que la connexion SQL Server est établie, l’application est en mesure de gérer les droits de l’utilisateur à l’application.
Les profils, ainsi que les restrictions de périmètre d’un l’utilisateur pour une application sont stockés dans la table CeaCentralAutorisations.UserPerimetre (cf. document de normes SQL du CEA).
Pour protéger ses données, chaque application code, à l’intérieur de procédures stockées, la jointure vers la table UserPerimetre. Chaque procédure stockée est autorisée en exécution pour tous les utilisateurs (grant execute to public on nomproc)
Cette protection des données est peu pratiquée en dehors du CEA. Elle est très performante car proche des données, et facile à maintenir car proche du code métier (à travers les procédures stockées).
La norme CEA délivre l’application « Cea.Normanet.Autorisations » qui permet de gérer, pour un utilisateur et une application donnée, tous ses rôles, profils et périmètres
4.2.3 Le s p a ra m è tre s
Les paramètres d’une application peuvent être stockés : - sur le(s) serveur(s) .Net
- sur le serveur SQL Server
Les caractéristiques du stockage de paramètres dans SQL Server sont : - Un point de stockage unique
- Accessible depuis les procédures stockées (très important pour les batchs) - Une mise à jour possible par des développeurs, administrateurs fonctionnels - Un temps de réponse de l’accès légèrement plus lent que pour un fichier Les caractéristiques du stockage de paramètres sur une plateforme .Net sont :
- plusieurs fichiers de configurations .Net à gérer dans un projet et plusieurs projets dans une application
- points de stockage multiples (gestionnaire de sources, postes développeurs, serveurs IIS) - Une mise à jour réservée aux administrateurs techniques (exploitants)
- Un temps de réponse de l’accès optimal La table SQL CeaCentralProperties.dbo.Properties
Nous recommandons de stocker par défaut tous les paramètres applicatifs dans la table SQL « Properties» livrée avec la norme via l’application Cea.Normanet.Properties.
Ces paramètres ne doivent pas avoir d’impact technique le bon fonctionnement de l’application et la responsabilité de l’exploitant/infogérant. En effet, ces paramètres seront gérés directement, en production, soit par le correspondant fonctionnel, soit par le correspondant technique, sans déploiement de composants.
Quelques exemples de contenu de la table Properties :
- chemin des images
- urls des liens hypertext (aide en ligne, documents, …) - texte infobulles
- adresses mail - …
Attribut Valeur
TAILLE_MAX_OBJECTIF 1300
URL_AIDE_CF http://www-drhrs.cea.fr/wp-
content/uploads/ForlandGuideUtilisateursCF.ppt pegasebatch.mail.suppPersonne. Bonjour,
DELAI_RELANCE_BF 30
statistique.activation True
rep.photos.web.pdf /geaDocs/photos MAIL_INTEG_FROM efacture@cea.fr
ad.cle UserPrincipalName
… …
La lecture de la table Properties s’effectuera dès l’ouverture de l’application.
Le fichier web.config
Le fichier web.config contient les paramètres techniques liés à l’application.
Sa mise à jour est effectuée par les développeurs via Visual Studio. Leur déploiement est lié à un build.
La déclaration de(s) database(s) SQL Server nécessaire(s) à un projet s’effectue dans le fichier web.config.
Quelques exemples de paramètres contenus dans le fichier web.config : - taille maximale des pages ASP
- nom de la database SQL Server - …
Le fichier machine.config
Le fichier machine.config est contient les paramètres techniques liés à la plateforme .Net. Ce fichier se situe dans le répertoire
%WINDIR%/Microsoft.Net/Framework64/v4.x (Serveur 64bits)
ou %WINDIR%/Microsoft.Net/Framework/v4.x (local poste de développement)
Sa mise à jour est effectuée par les exploitants/infogérants via un éditeur de texte et nécessite un arrêt/relance du/des processus IIS.
La chaîne de connexion traditionnelle proposée par MicroSoft contient, dans le fichier web.config, l’adresse du serveur SQL ainsi que la database associée. L’adresse du serveur SQL ne doit pas être stockée dans la solution VS, mais dans le fichier machine.config, qui dépend sur serveur IIS. Cette implémentation est indispensable pour rendre le build portable d’une plateforme à une autre.
Toute déclaration d’adresse de serveurs dans une solution Visual Studio est proscrite Quelques exemples de paramètres contenus dans le fichier machine.config :
- chaine de connexion SQL Server - chemin des fichiers de log - adresse du serveur SSRS - …
Si vous désirez ajouter de la sécurité sur le fichier machine.config, la ligne de commande suivante permet de le rendre illisible section par section :
Pour les configurations importantes (entreprise), le fichier entreprise.config pourra être utilisé.
App.config
La déclaration de(s) database(s) SQL Server nécessaire(s) à un projet du type client lourd s’effectue dans le fichier App.config.
Dans le cadre d’une solution portée sur un site Intranet / Internet, le fichier App.Config est cantonné au projet gérant l’ORM5.
4.2.4 Le d ia lo g u e a ve c S QL S e rve r
L’accès au moteur SQL Server s’effectue via des primitives de bas niveau assurant une haute performance (cf. génération syntaxe connexion en annexe).
Rappel : sauf exception validée par le chef de projet CEA, tous les accès à la base de données sont effectués avec des procédures stockées :
- Accès aux données d’une base depuis une application
- Alimentation d’un rapport SSRS à partir des données de la base L’interrogation de la procédure stockée a lieu de la manière suivante :
Les objets retournés doivent ensuite être convertis en objets Modèles pour pouvoir être affichés par la Vue (cf. les bonnes pratiques .Net en annexe).
Concernant le développement SQL, se référer au document de normes SQL du CEA.
4.2.5 La p a g in a tio n e t le s lis te s lo n g u e s
Pour afficher un tableau ayant une grande volumétrie, la pagination est à mettre en place au niveau du serveur SQL afin de ne pas surcharger le serveur Web. Se référer au document « 2 CEA - Normes SQL.pdf ».
L’utilisation de la librairie Kendo permet l’affichage de tableaux paginés.
4.2.6 Le s c o n ve n tio n s d e n o m m a g e d e s o b je ts
Nous vous recommandons d’appliquer strictement les conventions de nommage Microsoft. La présente norme ne propose aucune modification au standard.
Les conventions de nommage permettent de se repérer rapidement dans un langage donné.
.Net n’échappe pas à la règle et Microsoft a publié les conventions de nommage de son langage.
Le non respect de ces conventions de nommage entraîne une perte de temps significative pour le développeur qui assure la maintenance d’une application.
Ci-dessous les principales conventions à respecter.
4.2.6.1 Règles
Trois règles de nommages sont présentes dans le Framework .Net :
Nom Exemple
Camel Case Premier caractère en minuscule typeName
Pascal Case Premier caractère en majuscule AppDomain
Uppercase Tous les caractères en majuscules IO
5 Object Relational Mapper
public IEnumerable<User> GetAllUsers()
{ using (CEAEntities context = new CEAEntities()) {
ObjectResult<GetAllUsers_Result> result = context.GetAllUsers();
...
} }
aspnet_regiis -pef "appSettings" “D:\WebApp\WebApp1"
4.2.6.2 Principales conventions de nommage
Type Case Exemple
Classe Pascal AppDomain
Membres privé Camel + Underscore _message
Énumération Pascal ErrorLevel
Valeur d’énumération Pascal FatalError
Event Pascal ValueChanged
Exception Pascal WebException
Champ read-only et static / Constante Pascal RedValue
Interface Pascal IDisposable
Méthode Pascal ToString
Namespace Pascal System.Drawing
Paramètre Camel typeName
Propriété Pascal BackColor
Variable Pascal Result
Vue MVC Pascal SearchResult
Vue partielle MVC Pascal + Underscore Menu
Les méthodes et paramètres doivent porter un nom explicite afin de simplifier la lecture de code :
- Une méthode doit dire ce qu’elle fait et faire ce qu’elle dit.
- Une méthode doit commencer par un verbe (ex : GetUserByID) - Éviter les abréviations.
4.2.6.3 Cas particuliers
Les exceptions doivent toujours avoir leur nom suivi du mot « Exception ». Utiliser le snippet Exception pour ne pas l’oublier.
Les noms de classes doivent toujours être au singulier.
Exemple : AppDomain (et non pas AppDomains)
Les classes d’extensions doivent être suffixées par « Extension » : une classe statique d’extension de Page sera nommée PageExtension.
Les interfaces doivent commencer par un « I » (i majuscule) et dans la mesure du possible, finir par « able ».
Les membres privés doivent commencer par un underscore « _ ».
4.2.6.4 Acronymes
Longueur Acronyme Paramètre / Champ Nom de Classe
2 DB dbSettings DBSettings
3 Xml xmlAsString XmlWriter
4 Html httpRequest HtmlEncoder
Cette liste n’est pas exhaustive, la liste complète des conventions de nommage se trouve à cette adresse : https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-
guidelines
4.2.7 Le s re c o m m a n d a tio n s d e c o d a g e MVC
Le modèle MVC n’est pas seulement une bonne organisation du code. Il préconise également de bonnes pratiques basées sur l’utilisation de modèles et de templates dont le codage est indispensable pour la bonne maintenance du code.
L’application des 7 recommandations ci-dessous est indispensable pour la performance de la maintenance :
1. Utiliser au maximum les « EditorTemplates » et « DisplayTemplates » de manière à pouvoir réutiliser les formulaires (via DisplayFor et EditorFor).
2. Créer des méthodes d'extension à l'UrlHelper pour faciliter son usage dans les vues et dans les Contrôleurs
3. Développer des méthodes d'extension au HtmlHelper pour éviter d’alourdir le code de la page
4. Utiliser les DataAnnotations sur les modèles pour faire la validation coté serveur.
5. Ne pas utiliser les objets provenant de la source de données directement dans la Vue.
Créer des modèles pour cela. L’utilisation de mappers permet d’implémenter facilement la conversion d’objets.
6. Spécifiez les méthodes acceptées pour chaque méthode de contrôleur : [AcceptVerbs(...)], [HttpPost], [HttpGet] etc. sur chaque action du Controller.
7. Dans la mesure du possible, un Controller doit contenir les pages d’une même logique.
Par exemple : la création, modification et consultation d’un utilisateur (=> 3 pages associées dans ce cas)
D’autre part, nous recommandons de :
- Faire des tests unitaires pour la Vue et les services métier
- Valider les pages développées sur http://validator.w3.org/#validate_by_input
4.2.8 J a va s c rip t / J q u e ry / Aja x
Nous recommandons de bien gérer le nombre de méthodes utilisées de la librairie Jquery.
Plus son nombre est important, plus le risque d’avoir à gérer un impact d’une évolution est grand.
Les sources jQuery, jQueryUI et Kendo UI sont disponibles à travers le réseau StaticResourcesCea.
Voici une liste concernant l’utilisation de l’ajax à l’aide des frameworks jQuery : - Autocomplétion
- Treeview
- Listes en cascade
Cela permet de ne pas recharger toute la page et donc permet un gain de performance quand à l’affichage du résultat escompté.
Ne pas abuser de l’ajax pour la validation de formulaires simples afin de ne pas complexifier le code.
Les dernières versions du fichier kendo.all.min.js embarquent de plus en plus de fonctions, pénalisant ainsi les temps de réponses des navigateurs.
Nous vous recommandons fortement de personnaliser ce fichier avec l’outil https://www.telerik.com/download/custom-download.
A noter que la pagination grille n’est pas concernée, car nous recommandons de la gérer via SQL Server (cf. § « La pagination et les listes longues »).
4.2.9 Le s in ve rs io n s d e c o n trô le (Mic ro S o ft Un ity)
Afin de favoriser le découplage de l’application, la mise en place d’un Framework d’inversion de contrôle via le modèle d’injection de dépendance est fortement recommandée. Celle-ci permet :
- D’exposer les services de la couche métier - D’exposer les services d’accès aux données - De Fournir des outils au modèle MVC
La librairie recommandée pour cet usage est Microsoft Unity.
Plus d’informations sur ASP.NET MVC et DI: https://docs.microsoft.com/fr- fr/aspnet/mvc/overview/older-versions/hands-on-labs/aspnet-mvc-4- dependency-injection Et sur Unity : https://github.com/unitycontainer/unity
4.2.10 Le s e xp o rts d e d o n n é e s
4.2.10.1 Export simple type CSV
Ces exports sont à développer avec du code custom sans librairie externe. Les outils produits pour la génération de CSV peuvent éventuellement être découplés, généralisés afin de permettre une utilisation sur plusieurs projets.
Le séparateur de fichier normalisé au CEA est : TAB.
4.2.10.2 Export Excel simple
Un export Excel simple est composé de 50 champs plats et 1 tableau de moins de 20 colonnes. Un export Excel simple ne contient pas de graphiques, de styles complexes, de cellules calculées.
Pour un export Excel simple, nous recommandons l’utilisation de « Kendo UI ».
4.2.10.3 Export riche
Pour un export Excel avancé, nous recommandons l’utilisation de « OpenXML ».
Remarque : il s’agit là d’un exemple d’intégration avec MS Office.
Plus d’informations sur : http://msdn.microsoft.com/fr-fr/library/bb448854.aspx
4.2.11 Le s é d itio n s
Dans l’environnement Web, le développement des éditions n’est pas et ne sera jamais natif.
Aussi, nous vous recommandons ici le meilleur compromis existant.
En préambule, il est important de préciser que l’architecture Web permet de proposer, dans une même application, plusieurs techniques d’éditions. Il est nécessaire de choisir le bon outil pour chaque édition.
Afin de limiter le nombre de compétences différentes des développeurs (diminution des coûts) et de garder une certaine homogénéité pour ne pas perturber les utilisateurs, nous avons choisi deux outils et, in fine, 3 options possibles pour développer une édition.
Fig 18 – Choix des outils de développement des éditions
Notre recommandation vous propose donc seulement deux outils : HTML/CSS et SSRS6 avec 2 options (local et dédié). Cela répond à la majorité des besoins d’éditions.
Néanmoins, un cas d’utilisation n’est pas couvert : l’export Excel d’une édition sans prévisualisation à l’écran. Si cette fonctionnalité apparait ponctuellement indispensable pour une
6Sql Server Reporting Service
édition donnée dans une application, nous vous conseillons l’outil Aspose7. Il s’agit d’une librairie externe soumise à des droits de licence8.
A noter que nous ne considérons pas l’export Excel formaté d’une page HTML/CSS comme une fonctionnalité à couvrir.
CSS
Lorsque les rapports sont peu complexes et affichables dans un tableau permettant l’affichage, nous recommandons d’utiliser l’impression css à l’aide de la commande Javascript
« window.print() ».
La limite principale de ce développement réside dans l’impossibilité de gérer proprement le changement de page : ruptures, sous-totaux, etc..
Mais cela permet un gain de temps non négligeable quant à la réalisation d’un document imprimable. Dans ce cas, la prévisualisation est partielle : l’utilisateur visualise le corps de l’édition, identique à la page Web, mais sans les entêtes et les pieds de page. La génération du pdf s’effectue alors via PdfCreator qui doit être présent sur le poste client.
Nous recommandons d’essayer d’utiliser cette technique le plus souvent possible. Il s’agit du meilleur compromis entre le coût de développement et le service rendu à l’utilisateur.
SSRS en mode local
A partir d’un certain niveau de mise en forme avancée : les affichages conditionnels d’objets et d’une façon générale, tout ce qui concerne la gestion des ruptures de pages, l’utilisation d’un outil de reporting est obligatoire. Nous recommandons Reporting Services.
Pour les éditions peu volumineuses, nous recommandons d’utiliser Reporting Service en mode local. Le serveur d’application web héberge alors le rapport (fichier .rdlc9) qui se connecte à la base de données et supporte la charge de traitement.
L’interface de développement SSRS local est intégrée nativement à VisualStudio.
SSRS en mode serveur dédié
SSRS en mode serveur dédié sera nécessaire en cas de volumétrie. Il est très difficile de donner des abaques pour déterminer quand il faut exécuter les rapports sur un serveur dédié.
Outre l’obligation d’installer des serveurs SSRS dédiés (soumis à une licence d’utilisation), l’interface de développement SSRS dédié n’est pas intégrée à VisualStudio. Il faut installer et gérer les licences de la suite MS Business Intelligence.
L’architecture SSRS dédié n’est pas recommandée pour les petites applications.
4.2.12 Le s g ra p h iq u e s
On utilisera SSRS et/ou Kendo UI selon les besoins. Vous trouverez ci-dessous les cas d’usage de Kendo UI par rapport à Reporting Services.
Kendo UI DataViz Microsoft SSRS
Déploiement graphique localisés dans l’application (déportation des performances d’exécution et traitement côté client)
Déploiement centralisé sur serveur commun dédié ou partagé
Affichage des graphiques direct sans traitement du flux de données ou traitement limité
Besoin de traitement de données volumineux lors de l’affichage des rapports et graphiques
7 https://products.aspose.com/cells/net
8 L’informatique centrale n’a pas fait l’acquisition de licence Aspose. Si, à l’usage, le besoin est remonté, nous aviserons.
9 Report Definition Language Client-side
Besoin d’une génération des graphiques planifiée Intégration des graphiques sur portail
Graphisme riches et forte interaction avec l’utilisateur
4.2.13 L’e rg o n o m ie
Il s’agit d’apporter le maximum de confort et d'efficacité pour le plus grand nombre d’utilisateurs. Nous recommandons les respects de quelques règles.
Programmation des touches claviers
Dans un formulaire de saisie, l’utilisateur doit frapper des touches au clavier. Il est important de lui éviter des allers et retours entre la souris et le clavier pendant cette phase. Aussi, nous recommandons la programmation de :
- la touche ENTER pour valider le formulaire
- la touche TAB pour naviguer de champs en champs
Plus généralement, la saisie d’un formulaire doit pouvoir s’effectuer entièrement au clavier.
Pour plus d’information, consulter http://msdn.microsoft.com/en- us/library/windows/apps/hh700327.aspx
Positionnement des objets graphiques
Afin d’éviter aux utilisateurs de mémoriser d’application en application l’endroit où sont positionnés les éléments graphiques d’une page, nous recommandons le modèle de page suivant :
Objets graphiques Positionnement
Menus dans bandeau an haut horizontalement, sous le bandeau CEA Filtres (listes déroulantes, champs, radio-
boutons)
en haut et horizontalement sous les menus
Tree view bandeau vertical gauche
Eléments de conception/modification bandeau vertical droite
Cet affichage présente deux avantages par rapport aux menus situés dans un bandeau vertical gauche :
- Il permet de garder une surface maximum pour l’affichage du résultat.
- Il permet d’ajouter un tree view dans remettre en cause la disposition de la page Plus généralement, quel que soit le modèle choisi, tendre à n’en utiliser qu’un seul.
4.2.14 Le s te s ts u n ita ire s
Chaque solution Visual Studio doit posséder à minima un projet de tests unitaires. Il est aussi recommandé de séparer les tests selon s’ils sont dédiés à la partie Web ou à la logique métier.
Pour les projets MVC de type Tests, on distinguera :
Web.Tests Contient les méthodes de test de la couche Web. On parle de tests unitaires ou de tests automatisés d’IHM.
BusinessLogicLayer.Test Contient les méthodes de test de la couche Métier. On parle de tests unitaires
Le Framework de tests imposé est « MS tests framework »
Afin de garantir un meilleur découplage, la couche BusinessLogicLayer doit contenir une couche d’adaptation effectuant la conversion des entités d’accès aux données en objets de modèle.
D’autre part, Visual Studio délivre l’outil d’analyse « Code Analysis » qui permet d’identifier les problèmes de nommage et de casse. Nous vous recommandons l’utilisation des 2 tests suivants :
Règle Description Recommandée
CA1707 : Les identificateurs ne doivent pas contenir
Par convention, les noms d'identificateurs ne contiennent pas de trait de soulignement (_). Cette règle vérifie les espaces de noms, types, membres et paramètres.
Oui
de traits de soulignement
CA1709 : La casse des identificateurs doit être correcte
Par convention, les noms de paramètres utilisent la casse mixte et les noms d'espaces de noms, de types et de membres utilisent la convention de casse Pascal.
Oui
Remarque : le test CA1702 « La casse des mots composés doit être correcte » n’est pas recommandé.
Plus d’informations sont disponibles à l’adresse suivante : http://msdn.microsoft.com/en-us/library/ms182232.aspx
4.2.15 Le s te s ts d e q u a lité d e c o d e
Il existe sur le marché des outils d’analyse de performance de code, mais nous recommandons l’utilisation des utilitaires intégrés à la plateforme de développement Microsoft (Code Analysis). En effet, il est nécessaire de tester 5 langages (SQL, C#, Razor/ASP, JavaScript, Reporting Services).
L’outil Code Analysis propose un nombre important de tests d’écriture de code. Nous recommandons les deux tests suivants :
- CA1707 : Les identificateurs ne doivent pas contenir de traits de soulignement - CA1709 : La casse des identificateurs doit être correcte
C’est un exercice difficilement industrialisable. La revue de code visuelle par un expert reste, à notre avis, la méthode la plus efficace.
4.2.16 Le s b a tc h s
Un batch est un traitement différé (la nuit la plupart du temps) qui s’exécute sur la plateforme .Net.
Le codage de batch .Net est très limité. En effet, comme indiqué dans la norme SQL, les batchs « métier » doivent être codés au plus près des données, c’est-à-dire en SQL, dans des procédures stockées. Ces dernières étant ordonnancées avec l’outil utilisé par la plateforme de production.
Une application sera amenée à développer un batch .Net dans les cas suivants : - Purge de fichiers de logs ou de fichiers temporaires.
- Collecte d’informations sur les serveurs (modes agents par exemple) - Traitements de génération massive de fichiers
- Traitements d’exports - …
4.2.16.1 Structure
Chaque batch possède ses binaires et un dossier de travail.
Fig 19 – Livraison des batchs Les dossiers de travails sont :
- In : prends les fichiers d’entrée
- Out : écrit les fichiers de sortie - Log : écrit les logs de l’application
- Temp : Reçoit d’éventuels fichiers temporaires
Le seul dossier de travail obligatoire pour tout batch est Log.
4.2.16.2 Implémentation 4.2.16.2.1 PowerShell
Pour les batchs, il est recommandé d’utiliser PowerShell.
Un batch :
- Ne comporte pas de règles de gestion
- Comporte des transformations de données simples - Concerne une seule table
- Concerne un maximum de 10000 lignes - Concerne 20 colonnes maximum
- Utilise des interfaces simples à exploiter (procédure stockée, fichier csv…) 4.2.16.2.2 C#
Pour un batch développé en C#, on réutilisera les couches d’accès aux données de l’application web (avec parcimonie).
Ceux-ci disposeront d’un fichier start.ps1 lançant l’exécution du batch.
4.2.17 Le c h iffre m e n t
L’éditeur Prim’X a été retenu par l’ANSSI comme l’outil de chiffrement des données de l’état français. Aussi, l’utilisation des outils Prim’X est imposé pour le chiffrement des données (fichiers pdf par exemple).
A utiliser notamment dans le contexte de la protection des données Diffusion Restreinte.
Pré-requis :
- Générer un fichier .cer et un fichier .p12 - Enregistrer la dll Zedx 64 bits avec regsrv32
- Référencer le composant Zedx dans le projet (Project > Add Reference > COM > ZedX 3.0 Type Library)
- Lancer IIS en 64 bits
NormaNet délivre une méthode de chiffrement et une méthode de déchiffrement dans le template. Vous trouverez dans le répertoire BusinessLogic/Util, la classe ZedEncrypt10. Elle contient deux méthodes :
- saveEncrytedFile - readEncryptedFile
4.2.18 Me s s a g e s d ’e rre u rs
Nous identifions deux types de messages d’erreur à gérer lors des développements : - Messages d’erreur techniques
- Messages d’erreur métier
En fonction du type d’erreur, l’emplacement où le message d’erreur est géré pourra soit être la base de données, soit les fichiers de ressource applicative (dans chaque projet).
Ainsi, nous proposons que les erreurs techniques liées à l’applicatif soient gérées sur les fichiers de ressources attachés aux projets. Cette approche permet d’adapter ces mêmes messages aux exigences et besoins de log d’information technique.
Les messages d’erreur métier, dans l’optique de pouvoir les partager entre applications et/ou plateformes, il est alors proposé de les stocker en base de données. L’avantage de ce stockage en base de données est de pouvoir fournir le même message d’erreur pour une action semblable pour n’importe quelle application. Cette approche apporte à l’utilisateur un confort d’utilisation des applications.
10 Supprimer l'extension .txt (ZedEncrypt.cs.txt -> ZedEncrypt.cs) pour activer la classe.
4 . 3 LE S TE MP S DE R E P O NS E
La validation des temps de réponses est la partie cruciale et la plus délicate d’un développement. La performance d’une application implique des acteurs variés : les utilisateurs, les plateformes, les développeurs et les équipes techniques.
4.3.1 P e n d a n t le d é ve lo p p e m e n t
Afin de trouver le meilleur compromis entre le résultat et la disponibilité des acteurs, nous recommandons l’approche suivante :
- exiger de la part des développeurs d’effectuer des mesures « mémoire », « cpu » et
« entrées-sorties de données » sur les postes de développement .Net et SQL Server, en mode mono utilisateur sur un nombre de fonctionnalités représentatives
- Veillez à ce que ces indicateurs soient en dessous des seuils recommandés
Cette stratégie de mesure sur les postes de développements présente les avantages suivants :
- donne une très bonne probabilité de réussite à la montée en charge, - évite la mobilisation de la plateforme de production (ou pré-production), - évite l’intervention des équipes techniques,
- détecte les problèmes potentiels au plus tôt.
En plus des utilitaires natifs (IE -> F12 Developer Tools) et (Windows -> Performance Monitor), nous demandons l’utilisation du module open source ASP.NET MVC5 -> Glimpse.
F12 Developer Tools permettra de comprendre et de maîtriser la performance du navigateur (notamment le javascript)
Glimpse permettra de comprendre et de maîtriser la performance sur serveur IIS Express, ainsi que les échanges entre IIS Express et le navigateur.
Performance monitor permettra de comprendre et de maîtriser la performance de l’ensemble de l’application (navigateur, IIS et SQL Server), sur une période immédiate ou différée.
Fig. 20 – Utilitaire Glimpse (option Turn Glimpse = On et vue avancée)
Le temps de réponse total Request (Wire + Server + Client) ne doit jamais dépasser 2000 millisecondes sur le poste du développeur.
4.3.2 Ap rè s le d é ve lo p p e m e n t
Pour des applications sensibles, avec beaucoup d’utilisateurs et/ou des traitements lourds, l’approche précédente est insuffisante.
Une fois le développement livré, il est alors utile d’effectuer des tests qui permettent non seulement de valider la tenue à la charge, mais également de détecter les fuites de mémoires.
Nous recommandons l’outil Qtest™ de la société Quotium.
4 . 4 C O NS TITUTIO N DU P AC K AG E
L’exécutable IIS
Lorsque que vous disposez d’un serveur TFS, il est recommandé de générer le build de l’application via TFS. Le fait d’avoir un code exempt de toute référence à des composants système permet de générer un build natif, sans modification.
Il est interdit de gérer les variables référençant les adresses des instances SQL Server dans le fichier applicatif web.config.
Ces clés sont gérées dans les fichiers machine.config des serveurs IIS.
Les scripts SQL
Afin de rendre le processus de déploiement des scripts le plus sûr et le moins contraignant possible, NormaNet propose d’industrialiser l’exécution des scripts SQL via PowerShell.
A cet effet, NormaNet met à disposition la fonction NormaNetSqlCmd.ps1.
Avantage de la fonction NormaNetSqlCmd :
- ne nécessite aucune installation, fonctionne nativement sur tous les serveurs Windows - permet de ne pas utiliser SQL Server Management Studio (SSMS)
Attention : la librairie native .Net System.Data.SqlClient n’autorise pas le terminateur « go » Dans une configuration multi poste de développement, le poste VS Enterprise sert :
- à tester l’application dans son intégralité
- compiler et délivrer le build .Net de l’application complète pour déploiement11
- compiler (sur la base de données localdb) et délivrer les scripts SQL de l’application complète12
Structure de package
Le package (kit de déploiement) final, qui doit être remis aux équipes techniques, devra contenir, en plus du build IIS et des scripts SQL :
- les guides d’installation et d’exploitation - les batchs
11 Ces opérations peuvent également être effectuées avec le serveur TFS
12 Ces opérations ne peuvent pas être effectuées avec le serveur TFS (pas de base de données SQL)
Les packages devront avoir la structure suivante :
Fig 21 – Structure des packages
Remarque : aucune présence de fichier de variables à modifier par les équipes techniques (path d’installation, nom du pool d’application…).
Le cryptage de sections du fichier de configuration n’est pas abordé dans ce document.
Les assemblys des projets de tests unitaires ne doivent pas figurer dans le package de livraison de l’application.
Rajouter le déploiement du code SQL via le projet.
Gestion des dépendances binaires
Les dépendances binaires des projets sont les assemblys externes au Framework .Net qui sont nécessaires au projet pour compiler / fonctionner. Sur une machine de développement, ces assemblys sont présentes mais elles ne le sont pas sur un serveur de production. Il est donc nécessaire de prendre des précautions pour ne pas avoir une exception « could not load assembly XXXX »
Le dossier binaries aura donc cette forme :
Fig 22 – Gestion des dépendances binaires
Les projets Visual Studio doivent référencer les assemblys dans le dossier Binaries avec l’option « copy local = true ».
Les assemblys doivent être ajoutées au source control du projet.
