Bénéfices du développement logiciel Model-First. Livre blanc CodeFluent Entities

Bénéfices du développement logiciel Model-First Livre blanc CodeFluent Entities Daniel Cohen-Zardi Version 5.0 Juin 2014 1

Comment le développement logiciel Model-First peut vous aider à réussir vos projets Sommaire I. Le défi du développement logiciel... 7 II. Approches traditionnelles... 9 1. Outils RAD... 9 2. Ateliers de Génie Logiciel... 9 3. Off-shore... 10 III. Notre expérience terrain des échecs... 13 1. Manque de compétences... 13 2. Manque d expérience et geek attitude... 13 3. Sur-ingénierie et frameworks... 14 IV. Proposition de modèle pour l Equation du succès... 17 V. Nos convictions... 21 VI. Les bénéfices de l approche Model-First à travers des scénarios classiques... 25 1. Rester flexible et à jour avec la technologie... 25 2. Absorber les changements fonctionnels... 29 3. Etendre et personnaliser... 31 4. Réduire les dépendences... 34 VII. La méthode agile procurée par CodeFluent Entities... 39 1. Description de CodeFluent Entities... 39 2. Les principes de CodeFluent Entities... 39 3. Aperçu de CodeFluent Entities... 41 4. L agilité avec CodeFluent Entities... 41 5. Etapes recommandées pour un usage basique... 42 6. Etapes recommandées pour une utilisation avancée... 46 VIII. Conclusion... 53 IX. Annexes : liens clé... 57 X. A propos de SoftFluent... 59 1. Qui sommes-nous?... 59 2. Notre vision... 59 3

Comment le développement logiciel Model-First peut vous aider à réussir vos projets Avant propos L objectif de ce livre blanc est de décrire le défi que représente le développement logiciel, clarifier les causes et montrer comment SoftFluent parvient à le relever grâce à sa fabrique logicielle Model- First CodeFluent Entities et à la méthodologie que nous lui avons associée. La première partie du document explique le défi du marché et pourquoi c est un problème économique difficile : Chapitre 1, nous expliquons la nature structurelle du défi du développement logiciel, Chapitre 2, nous commentons les approches traditionnelles qui existent sur le marché, Chapitre 3, nous détaillons nos observations terrain relatives aux échecs de certains projets particulièrement fréquents avec les nouvelles technologies (dont l ouverture comporte plus de risques que l héritage traditionnel plus restreint), Chapitre 4, nous proposons une «Equation du succès» comme modèle pour résumer ces éléments. Nous tenons à souligner que cette partie est largement applicable par toute personne intéressée par le développement logiciel indépendamment de notre offre. Dans la seconde partie de ce document, nous exposons la solution que nous avons élaborée pour répondre structurellement au défi : Chapitre 5, nous présentons nos convictions qui ont guidé la conception de notre solution pour dépasser les limites des approches traditionnelles, Chapitre 6, nous listons les scénarios typiques du développement logiciel pour illustrer les bénéfices concrets liés à l utilisation d une approche partant du modèle comme celle que nous proposons. Chapitre 7, nous détaillons les différentes étapes de notre méthodologie en utilisant l ap proche CodeFluent Entities pour modéliser, développer et industrialiser la production, Finalement, CodeFluent Entities est une recette pragmatique pour réussir vos projets de développement logiciel. Cette recette n est peut-être pas unique mais elle a déjà démontré être d une valeur considérable pour nos clients. Nous concluons avec le chapitre 8 en expliquant pourquoi l approche Model-First est si structurellement importante et est la solution à l évolution du défi détaillé dans ce livre blanc. SoftFluent, 2010-2014 - Ne pas dupliquer sans autorisation. CodeFluent Entities est une marque déposée de SoftFluent. Tous les autres noms de société et de produit sont des marques déposées de leurs propriétaires respectifs. Les éléments présentés dans ce document sont par nature synthétiques, sujet à évolution, non contractuels et communiqués uniquement à des fins d information. 5

I Le défi du développement logiciel 6

Comment le développement logiciel Model-First peut vous aider à réussir vos projets I. Le défi du développement logiciel Etre en charge d une équipe de développement logiciel dans les années 2010 n est pas le poste le plus enviable qui soit. Alors que les attentes des utilisateurs ne cessent d augmenter, les moyens s accompagnent de plus en plus de contraintes. Quand un secteur progresse, cela se traduit inévitablement par des besoins fonctionnels de plus en plus sophistiqués. En parallèle, les utilisateurs sont de plus en plus exigeants sur les technologies et l expérience utilisateur conformément à leur vécu de consommateur individuel. Le fait qu ils utilisent des logiciels packagés produits pour des millions d utilisateurs avec des investissements conséquents ne doit pas aider l équipe IT à contenir voire réduire les attentes de ces utilisateurs dans le cadre professionnel. En fait, l équipe de développement doit digérer l innovation technologue et apporter des solutions prêtes à l emploi. Le défi est d autant plus difficile à relever que le rythme de l innovation technologique d accélère avec une complexité croissante difficilement gérable. A cela s ajoute la pression des réductions budgétaires et des délais à laquelle la plupart des équipes IT ont à faire face ; les développeurs sont structurellement coincés entre les attentes fonctionnelles et l évolution technologique. Décideurs Besoins flous Besoins qui évoluent Augmentation des attentes Moins d argent Moins de temps DSI Technologies Nouvelles technologies Compétences pointues rares Équipe hétérogènes Poids croissant du code à maintenir A ce stade, vous pourriez être tenté d embrasser une autre carrière et nous vous recommanderions peutêtre de le faire si vous le pouvez! Mais si, comme pour nous, il est déjà trop tard, nous vous invitons à poursuivre votre lecture. 7

II Approches traditionnelles 8

Comment le développement logiciel Model-First peut vous aider à réussir vos projets II. Approches traditionnelles Le développement logiciel est une discipline âgée d une cinquantaine d années, on peut donc s étonner du fait qu aucune solution n existe à ce jour. Passons en revue les différentes approches qui ont été tentées et faisons la lumière sur leurs principales limites. 1. Outils RAD Comme le temps du développeur se révèle coûteux, cela fait bien longtemps que des outils de génie logiciel ont tenté d accélérer ce processus par différents moyens, en particulier la génération de code. Certains outils connus, catégorisés sous la notion de RAD (Rapid Application Development), tels que PC Soft Windev ou 4D, procurent actuellement un bon moyen de livrer une application dans un délai relativement court. Différents prototypes peuvent rapidement aboutir à des résultats alléchants avec un processus simple. Cependant, si ces applications atteignent un certain niveau de complexité, les outils se révèlent souvent incompatibles avec la sophistication des fonctionnalités demandées, dans la mesure où ces outils sont très efficaces pour répondre à leur fonction de base, mais incapables d une quelconque valeur ajoutée dès lors que celle-ci n a pas été prévue au départ. Le principal problème pour les clients est alors d être incapables de répondre aux exigences fonctionnelles pour leurs applications. Ce n est pas un risque acceptable pour les clients d une manière générale. 2. Ateliers de Génie Logiciel Les Ateliers de Génie Logiciel (AGL) existent depuis longtemps, et ont été largement vulgarisés pendant la vague client/serveur des années 90. Les outils tels que Powerbuilder, Progress, Magic, NS-DK ou Centura ont pris leur essor à cette époque. Ils ont beaucoup investi pour fournir un modèle de programmation pour les applications client/serveur et ont rencontré un réel succès à la fois sur le marché mais aussi en gains de productivité. Ils simplifiaient notamment les langages complexes tels que C++, langage standard à l époque. Mais, ces AGL ont perdu de leur popularité essentiellement en raison de l émergence d un tout nouveau modèle de programmation avec le Web. La conséquence a été que bon nombre de clients, poussés par les vendeurs de plateformes logicielles, se sont à nouveau focalisés sur des langages tels que Java ou C# perdant ainsi le gain qu ils avaient acquis en utilisant des outils à haut niveau d abstraction. Une autre raison était la crainte de certains clients d être verrouillés dans l environnement d un fournisseur, dans la mesure où ces outils fournissaient leur propre langage de programmation. Finalement le principal problème pour les clients relevait de leur incapacité à se maintenir à jour des technologies, dans la mesure où la contrepartie de ces offres était la lenteur de leur évolution. En fait, à ce jour il n existe pas d AGL efficace pour les applications Web. Ce n est pas une situation tenable à long terme pour les clients. 3. Off-shore Une autre approche que beaucoup de sociétés ont tentée notamment dans les années 2000 a été de réduire le coût des ressources via l off-shore. 9

Livre Blanc CodeFluent Entities Bien que cela semble économiquement alléchant avec des coûts de main d œuvre variant de 1 à 10 suivant les pays, cette solution est loin de tenir ses promesses. En fait lorsque cela fonctionne - cela ne répond pas fondamentalement au défi, mais diminue simplement le coût apparent des ressources de développement, tout en ajoutant par ailleurs de nouvelles difficultés et en faisant peser de nouveaux risques sur le projet. On pourrait écrire un livre sur l off-shore, mais pour résumer, éloigner l équipe de développement l empêche d augmenter son savoir-faire et ne répond pas à notre défi. Au contraire, les personnes expérimentées en développement logiciel savent que le coût total d une application doit inclure les coûts de maintenance. Cette phase est souvent bien plus longue que la phase de développement initial. Et ce qui peut paraître économique à court terme se transforme souvent en coûts additionnels et en perte d agilité à long terme. Tout développeur expérimenté sait que les possibilités d évolution d une application mal conçue sont faibles alors que toute évolution, même mineure, devient de plus en plus coûteuse. Le principal problème avec l off-shore est qu il est souvent guidé par une pure recherche de réduction des coûts, avec au final un projet livré au détriment de l industrialisation et de la maintenance. Selon nous, ces trois approches comportent des limites intrinsèques en plaçant l accent de façon exagérée sur respectivement les délais, le périmètre et les coûts. Accent sur DÉLAI Solution Outils de dévt rapide Inconvénients: Fonctionnalités contraintes Coût de personnalisation prohibitif Dépendance Accent sur COÛT Solution Offshore Inconvénients: Industrialisation faible Coûts de maintenance élevés Risque sur les délais Besoin d une solution équilibrée Accent sur PÉRIMETRE Solution AGL Inconvénients: Retard sur l innovation technologique Manque de flexibilité Compétences et langages spécifiques Ces trois paramètres doivent être équilibrés de manière appropriée et c est pourquoi nous privilégions une autre méthode pour relever le défi du développement logiciel. 10

III Notre expérience terrain des échecs 12

Comment le développement logiciel Model-First peut vous aider à réussir vos projets III. Notre expérience terrain des échecs Parce que nous avons de l expérience dans le développement logiciel, il nous est souvent demandé d effectuer des missions d audit sur le développement.net pour analyser la qualité d une application, sa capacité d évolution, sa flexibilité et son exploitabilité dans un contexte de production. En premier lieu, il est important de préciser que nous sommes étonnés par la grande proportion des projets qui échouent et l accumulation de défauts. Nous rencontrons souvent des échecs se chiffrant en millions d euros et il est assez commun d en conclure qu une bonne moitié du code pourrait être évitée en utilisant des bibliothèques appropriées, la plupart du temps disponibles dans le Framework.NET lui-même! Il est intéressant de noter l existence de syndromes typiques que nous avons observés chez certaines équipes de développement et que nous résumons ci-dessous. 1. Manque de compétences La première raison est le simple manque de compétences. Dans la plupart des cas, même les développeurs expérimentés peuvent manquer de compétences dans les nouvelles technologies. Alors que la complexité des couches techniques était généralement masquée avec les AGL, ce n est désormais plus le cas avec le nouveau défi posé par la large ouverture des environnements, qui mène à encore plus d écueils. Dans cette situation, nous constatons que le code fonctionne jusqu à ce que le projet se complexifie en périmètre ou en volumétrie. Comme le code est produit manuellement, avec des styles hétérogènes fluctuants, la maintenance est de plus en plus compliquée avec une inflation des coûts pour la moindre modification jusqu à ce que l équipe se retrouve finalement face un mur. Dans ce cas, le premier facteur d échec est : le déficit de compétences. 2. Manque d expérience et geek attitude A contrario, nous rencontrons souvent de jeunes développeurs plutôt intelligents et à l aise avec les nouvelles technologies. Mais ils peuvent manquer d expérience entreprise et la plupart d entre eux ont tendance à adopter la geek attitude, un comportement qui consiste à se focaliser sur chaque nouvelle technologie, dès qu elle apparaît. Dans ces situations, les développeurs se concentrent sur la beauté du code, une seule ligne de code pour une instruction très compliquée, qui satisfait son ego de développeur mais n apporte aucune valeur intrinsèque. En fait, cela peut même porter une valeur potentiellement négative et accroître les coûts de maintenance. Ces jeunes développeurs perdent souvent le sens des objectifs fonctionnels dans la mesure où les utilisateurs ne sont pas leur principal centre d intérêt ; de plus, ils n ont pas le niveau d expérience pour comprendre les contraintes d exploitabilité et les nécessités d instrumentation du code. En raison de ce manque d expérience, il n est pas rare qu ils sous-estiment les enjeux de flexibilité, et les applications qu ils conçoivent sont généralement peu performantes avec l augmentation du volume de données et du nombre d utilisateurs. Ce genre d applications est généralement difficile à maintenir et nécessite d être optimisé voire réécrit dans les domaines nécessitant de la performance. 13

Livre Blanc CodeFluent Entities Ce type d échec traduit en fait un manque de méthode éprouvée. 3. Sur-ingénierie et frameworks Ce type de cas mène aux situations les plus coûteuses et concerne essentiellement les grands comptes. Dans ce troisième syndrome, un (ou plusieurs) architecte de génie est mandaté pour inventer une solution personnalisée pour l équipe de développement. Généralement cet architecte est très intelligent, et c est en partie le problème, car il se croit capable d inventer toutes les solutions pertinentes pour le projet. Il commence donc à concevoir potentiellement avec une équipe de développeurs un framework supposé être la recette optimale pour le projet mais elle va souvent bien trop loin. Mettre le bon niveau d abstraction pour un projet nécessite de placer le curseur au bon endroit sur le schéma ci-après : Normalisation & factorisation Orientation objet Fait de composants Dénormalisation Procédural Monolithique Où placer le curseur? Inconvénients Complexité du noyau Compétences requises Risque de perfectionnisme Où s arrêter? Inconvénients Augmentation des délais Coûts de maintenance Peut devenir difficile à gérer Avantages Réutilisation Capacité d évolution Contrôle Possibilité de tests Avantages Simple Exige peu de compétences Indépendance des équipes Démarrage rapide des projets Le Où s arrêter? à gauche est une question cruciale, car selon notre expérience, c est là que la situation se détériore alors même que l idée de concevoir un «framework» peut paraître bonne. L expérience montre que : 14 Concevoir un framework flexible susceptible de faire face à toutes les situations avec les nouvelles technologies évolutives est ardu et risqué,

Comment le développement logiciel Model-First peut vous aider à réussir vos projets Le risque d échec avec un framework qui ne fonctionne pas est énorme, avec potentiellement un «effet tunnel» pendant le développement du framework, cette phase est alors perdue inutilement, Dans les cas les plus favorables, le framework apporte de la valeur mais ne résiste pas à une nou velle vague technologique, à moins de réinvestir fortement pour être toujours en adéquation avec les nouvelles technologies et prévenir un autre échec, Dans la plupart des cas, le framework ne peut pas être maintenu par une personne autre que l architecte lui-même. Bien que n étant pas toujours admise, cette situation provoque des échecs économiques significatifs. Si, parfois, les AGL sont perçus comme un problème en plaçant le client dans une situation de dépendance vis-à-vis d un fournisseur, le syndrome décrit ici, à savoir la dépendance vis-à-vis d un architecte, est bien pire. Le risque consistant à dépendre d une seule personne est autrement plus inquiétant encore que de dépendre d un fournisseur établi dont la stratégie repose sur une offre conçue pour cela. Ce cas d échec est caractérisé par un surinvestissement dans l outillage, un facteur qui est difficile à maîtriser et dont la complexité est souvent fortement sous-estimée. 15

IV Proposition de modèle pour l Equation du succès 16

Comment le développement logiciel Model-First peut vous aider à réussir vos projets IV. Proposition de modèle pour l Equation du succès Le rapport Chaos 1, même dans sa version de 2009, rapporte que moins du 1/3 des projets IT sont couronnés de succès, livrés à temps et dans le budget avec les bonnes caractéristiques. Cette interprétation est contestée par d autres points de vue comme l étude de Dr Dobb 2 qui a une approche différente du succès en demandant aux personnes qui ont livré le projet, ce qui peut aussi être biaisé selon nous. La réalité se situe probablement au milieu mais ce que nous savons avec notre expérience terrain, c est que le risque est toujours très présent surtout lorsque l on introduit une nouvelle technologie dans un environnement très contraignant. En fait, la probabilité de succès d un projet peut se résumer à l équation suivante : Si le savoir-faire est supérieur aux ambitions, le projet a toutes les chances de réussir. Cela apparaît finalement simple à comprendre. Si on ajoute à cela les considérations liées aux attentes évoquées dans l introduction, on peut considérer que: Notons que la tendance sur chaque composante fait évoluer défavorablement la situation, et l ambition ne cesse d augmenter de façon cubique! Il est clair que les projets de développement logiciel ne peuvent pas réussir sans une approche permettant au savoir-faire d évoluer plus vite que l ambition. En fait sans changement structurel d approche, les équipes de développement n ont aucune chance de réussir sur le long terme. C est ce que nous avons pu constater sur le terrain où bien que souvent masqués les coûts explosent et le volume de code antérieur obsolète ne cesse de croître, faisant peser le poids de la maintenance sur les équipes de développement. Donc y a-t-il un espoir de maîtriser l ambition ou est-ce peine perdue? Si l on considère le savoir-faire comme la combinaison de trois éléments clés constituant les facteurs majeurs de succès des projets de développement : URL 1 : http://www.pmhut.com/the-chaos-report-2009-on-it-project-failure URL 2 : http://www.drdobbs.com/architecture-and-design/2010-it-project-success-rates/226500046 17

Livre Blanc CodeFluent Entities Notre équation est soluble à la seule condition d améliorer en permanence les compétences, la méthode et les outils. C est exactement ce que propose notre approche du développement logiciel, basée sur une méthode itérative pilotée par les modèles, appuyée par un outil qui améliore le processus de développement. La responsabilité de l équipe de développement est, par conséquent, focalisée sur le maintien des compétences, un processus d autant plus simplifié qu une partie de la complexité des technologies est automatiquement digérée. 18

20 V Nos convictions

Comment le développement logiciel Model-First peut vous aider à réussir vos projets V. Nos convictions Parce que chez SoftFluent, nous avons passé beaucoup d années sur des projets de développement, nous avons tiré parti de cette expérience pour concevoir une nouvelle recette susceptible de garantir le succès des projets malgré l évolution des technologies. Notre approche du développement est construite sur le succès des recettes passées, telles que les AGL, mais avec quelques différences structurelles ciblées pour relever le défi. Inconvénients historiques En retard sur les plates-formes et technologies récentes Solution La conception métier est structurellement séparée de la cible technique avec une évolution garantie par des producteurs spécifiques Exige une définition stable des besoins métier des utilisateurs La modélisation produit immédiatement des composants exécutables qui supportent un processus de conception compatible avec le changement Coûteux à personnaliser au-delà des éléments préconçus dans l AGL Le code généré est standard, lisible, structuré en composants et peut être personnalisé sans limite Dépend d un langage et de compétences spécifiques Totalement intégré dans l outil de développement habituel, le code est standard dans la mesure où la solution ajoute juste une fine couche d abstraction L analyse des inconvénients historiques des AGL nous a aidés à forger nos convictions intimes et constitue le cœur de notre méthode de développement partant du modèle. 21

Livre Blanc CodeFluent Entities 1 2 3 4 Les entités métier ont des cycles de vie plus longs que la technologie et doivent donc être définies dans un format qui résiste aux évolutions technologiques, qui puisse les supporter sans avoir à reconcevoir l application. Les règles métier et les changements de processus doivent avoir des cycles courts compatibles avec un schéma de maintenance continu. Un couplage efficace entre les couches de données, de modèle métier et de présentation incluant tout ou partie du code personnalisé, doit être garanti par conception. Les patterns de code doivent être homogènes et l implémentation automatisée de sorte que la maintenance puisse être effectuée par des compétences standardisées. 22

VI Les bénéfices de l approche Model-First à travers des scénarios classiques 24

Comment le développement logiciel Model-First peut vous aider à réussir vos projets VI. Les bénéfices de l approche Model-First à travers des scénarios classiques Au-delà des convictions théoriques, il est important de comprendre à travers des exemples très concrets de notre offre produit CodeFluent Entities, pourquoi vous allez gagner à utiliser une approche Model-First pour relever le défi du développement logiciel. 1. Rester flexible et à jour avec la technologie a) Plateforme de base de données à support multiple Prendre en charge différents systèmes de base de données, physiquement ou dans le Cloud est un bénéfice immédiat de l utilisation de CodeFluent Entities. Les producteurs de persistance génèrent des scripts du modèle et les déploient sur la base de données spécifique pour créer votre couche de persistance. De plus la couche de persistance utilisée est indépendante des couches supérieures (classes.net, services, interfaces utilisateur) par conséquent changer de système de base de données revient à changer de producteur (par exemple MySQL et PostgreSQL). 25

Livre Blanc CodeFluent Entities b) Ajouter des nouvelles technologies avec un réinvestissement minimum Alors que le rythme de l innovation s accélère, être capable de suivre les nouvelles technologies est de plus en plus difficile. C est une des plus grandes valeurs du produit au fil du temps car il va permettre d éviter l inflation de la dette applicative dont tous les analystes parlent. Grâce à l approche du produit CodeFluent Entities basée sur les producteurs, vous pouvez accélérer le support d une nouvelle technologie (comme Windows 8 dans l exemple) en générant une part significative de la «plomberie». A titre d exemple voyons le même formulaire généré par des producteurs différents d interfaces utilisateur standards : ASP.NET Ajax ASP.NET MVC 26

Comment le développement logiciel Model-First peut vous aider à réussir vos projets ASP.NET Webforms SharePoint Webpart 27

Livre Blanc CodeFluent Entities Windows Presentation Foundation Windows Design Language (Windows 8) 28 c) Implémenter des scénarios d architectures multiples Avec le développement du web, la multiplication des périphériques et le développement du Cloud, beaucoup d applications nécessitent des scénarios d architecture multiples, combinant certaines des technologies suivantes :

Comment le développement logiciel Model-First peut vous aider à réussir vos projets web, client riche, services basés sur le Cloud, terminaux mobiles. Dans ces scénarios, sans une approche Model-First vous aurez besoin de coder les concepts dans toutes les couches avec des conséquences importantes en coût de maintenance et difficulté de cohérence, alors que CodeFluent Entities vous garantira la centralisation de votre code clé et de vos règles, et la répercussion dans toutes ces architectures. Enfin, l expérience terrain montre que l architecture peut évoluer au fil du temps. Des applications conçues avec une certaine architecture sont parfois mises au défi de passer sur d autres ou de prendre en charge des scénarios qui nécessitent une architecture différente (web, Cloud ou mobile par exemple). Si cela se produit, vous saurez beaucoup mieux réagir et vous adapter si vous utilisez un outil Model-First. 2. Absorber les changements fonctionnels a) Centraliser le travail Avec CodeFluent Entities, vous pouvez transformer des éléments de conception décrits dans une approche de modélisation visuelle et simple en code utilisable dans toutes les couches (il n est nul besoin d apprendre certaines notions complexes qu on retrouve par exemple dans UML comme on le voit ci-dessous). L ajout d une entité, une propriété, une règle ou une vue se fait au niveau du modèle et génère instantanément tous les composants sur toutes les couches nécessaires à votre architecture. Note : ce n est pas le cas avec une approche code-first dans la mesure où elle est connectée à une technologie et un langage spécifiques qui ne permettent pas la répercussion sur différentes couches, comme la base de données ou l interface utilisateur. 29

Livre Blanc CodeFluent Entities b) Générer en continu Grâce à cette approche Model-First, le principe Don t Repeat Yourself (DRY) est respecté. Le produit est basé sur l idée de générer en continu tout en préservant votre personnalisation, simplifiant l absorption des changements fonctionnels. Par conséquent, vous n avez à maintenir que votre code personnalisé, le code généré étant mis à jour automatiquement par CodeFluent Entities. Qui peut garantir qu il n aura pas à ajouter une propriété à une entité relativement tard dans le cycle du projet obligeant à mettre à jour régulièrement plusieurs couches? Ce n est pas un problème avec CodeFluent Entities et vous avez la garantie par conception que votre modèle objet est toujours aligné avec le modèle de conception. Partie intégrante du processus de génération en continu, le moteur différentiel de base de données permet des mises à jour de schémas automatiques sans perdre de données. Supposons que vous ayez une entité client existante : Depuis laquelle vous générez une table client contenant des données : En ajoutant une propriété Name à l entité : 30

Comment le développement logiciel Model-First peut vous aider à réussir vos projets La génération préservera vos données existantes : Des opérations telles que l upcasting, l ajout/suppression des contraintes ou relations sont entièrement prises en charge de sorte que vous pouvez générer en continu tout au long de vos développements. c) Homogénéiser Une autre valeur ajoutée clé de l approche Model-First est la capacité à homogénéiser l implémentation de toute l application. La facilité à implémenter les conventions de nommage en est un exemple : Avec une approche «code-first», vous ne pourriez pas facilement appliquer une convention de nommage globale ou la modifier à partir d un point central si nécessaire. 3. Etendre et personnaliser a) Garder le contrôle de la performance et de l évolutivité Bien que abstraction signifie plus de flexibilité, la façon d y parvenir via les ORM génère des défis sérieux de performance et d évolutivité, tout comme la possibilité donnée au développeur d effectuer des choix de «mapping» risqués. En raison de son approche respectueuse des bases de données et des administrateurs de base de données, CodeFluent Entities surpasse les alternatives ORM 1 en permettant de cibler plusieurs bases de données. En fait, CodeFluent Entities fournit une réelle continuité entre le modèle objet généré et la base de données avec une réponse pragmatique à la rupture d impédance entre les mondes objet et relationnel. Par exemple, une hiérarchie d entité sera traduite en suivant le pattern de «Table per type» dans la couche de persistance alors que dans le modèle objet généré, ce sera un héritage de classe classique. Supposons que vous avez la hiérarchie suivante : URL 1 : http://blog.codefluententities.com/2012/06/05/codefluent-entities-performance-comparison/ 31

Livre Blanc CodeFluent Entities Voici la représentation générée en base de données du modèles : Que les méthodes d accès aux données générées (basées sur des procédures stockées) prendront en charge automatiquement : Autre bon exemple de cette continuité, le fait que vous n aurez jamais à vous débattre avec les gestion des nulls, DBNull et les conversions de données : l outil se charge de tout pour vous afin que vous n ayez pas à le faire. b) Créer vos propres aspects 32