Bonjour,

C’est avec grand intérêt que je lis parfois quelques débats plus ou moins houleux sur ce forum (entre autre) et en dehors de certaines remarques parfois irrespectueuses, je dois avouer que l’on y apprend pas mal de choses. Voilà pour le contexte général.

Mes premiers pas avec le développement remontent à un peu moins de 30 ans (l’âge que certains d’entre vous n’ont sans doute même pas encore atteint) avec un vulgaire basic sur une vulgaire machine grand public. Puis des études avec en point de mire le COBOL sur un Bull Mini 6, dont je garde d’ailleurs de bons souvenirs car ce fût sans doute ma meilleure formation au développement itératif et procédural. Il y a bien entendu eu C, Pascal et autres joyeusetés après cela mais ma grande histoire d’amour a été ma rencontre avec dame « Le Lisp de l’Inria ». Ce langage a une composante « magique » que je n’ai jamais retrouvée depuis. Voilà pour le contexte scolaire.

S’en suivent une vingtaine d’années de quasi vide en termes de développement. Il y a bien eu un obscur langage L4G like pendant 2-3 ans au début et de courtes rencontres autodidactes avec l’environnement visual studio et C# (je reste de ces gens pour qui le Basic , qu’il soit bon ou non, reste à éviter) mais rien d’important. Ce fut tout au plus une forme de « suivi » qui me permettait encore de temps à autre de comprendre ce dont on parlait dans l’univers du développement. Après tout, compte tenu du timing de tout ça, je ne suis pas né avec l’objet et l’évènementiel en guise de jouets dans ma poussette. Bref en terme de bilan de l’existant, je note quelques petites expériences avec C# / ASP .NET essentiellement. Voilà pour le contexte professionnel.

Bref on me demande il y a quelques mois de reprendre une petite application de gestion de cantine (réservation, gestion des menus, facturation aux employés etc….) initialement développé en Acces (sic !!!). Je me suis lancé de suite dans la seule composante que je maitrisais encore à peu près correctement, c’est-à-dire la définition du SGBDR avec en préambule la constitution d’un pseudo Modèle Conceptuel de Données. Le choix du langage de développement sera sans aucun doute le C#, pour des raisons de goûts et de ressources. Mais depuis s’est mis en place un maelstrom d’idées, de voies à emprunter qui ne débouchent sur aucun schéma concret. Voilà pour le contexte du projet.

En temps normal on demande à un développeur de résoudre au plus vite un problème avec les outils qu’il a en sa disposition sans se poser trop de questions stériles sur l’évolutivité , la pérennité ou « la beauté » du choix retenu. Malheureusement ce n’est pas ma tasse de thé et évoluant non pas dans le secteur prestataire de service, mais entreprise de production, c’est un luxe dont je peux encore jouir.
Mes axes de réflexions sont au nombre de 2 essentiellement.

1) La gestion des données

Me voilà donc avec mon MCD quasiment validé qui devait être implémenté sur SQL Server 20xx. Bien entendu la gestion des données métiers se fera en objet. Reste donc l’éternelle « interface » entre les deux. Premier réflexe, l’ Entity Framework qui rendait la chose quelque peu « transparente ». Première interrogation, Objets générés à partir de la définition du SGBDR ou SGBDR généré à partir de la définition des objets métiers ? Ayant déjà défini le MCD je partais plutôt à partir de la première approche. Toutefois j’ai lu à droite et à gauche que quel que soit le cas de figure, le code ou la base de données générés n’était ni « propre » ni optimale. Quelqu’un a-t-il une expérience de la chose ?
Suite à ça j’ai exploré quelques voies parallèles dans le domaine SGBDR avec SQLLite qui parait il est bien plus efficace dans de petits projet.
Mais comme il restait ce principe d’ORM j’ai lorgné du coté MongoDB mais pas indiqué du tout ici ou DB4o qui semble plus intéressant.

Questions :
- En cas d’usage de SGBDR, ici sans doute SQLlite, faudrait-il gérer l »interface » Objets/Métiers <-> SGBDR à la main ou laisser Entity Framework s’en charger ?
- DB4o serait-il un meilleur choix ? Ca me forcera juste à partir non pas sur la Base de données mais reprendre le projet via la définition des objets métiers

2) Le choix « technique »
Dès le début j’ai voulu toucher un maximum de plateformes. Partant sur une petite expérience ASP.NET j’avais envisagé la techno WEB dans un premier temps.
Entre temps Microsoft s’est engouffré dans la technologie HTML5/CSS3/Javascript qui a l’avantage de pouvoir toucher tout browser, de déporter une partie des traitements du serveur vers le client (en comparaison d’ASP.NET) et d’être plus pérenne.
Seulement voilà, je ne cesse de crier partout que la mort du développement c’est cette manie de rajouter des couches d’abstraction virtuelles un peu partout (cas extrème Wmvare/NetFramework/Browser) et donc ce n’est pas réellement ma façon de voir.
Il y a peu je suis tombé sur cet excellent article dans un blog : http://www.e-naxos.com/Blog/post/Strategie-de-developpement-Cross-Platform-Partie-1.aspx
Le cross plateform. Un noyau sur un serveur avec la partie métier et via un découpage MVVC, seule l’UI devra être adapté pour chaque plateforme. Développement en C# uniquement avec tec Xamarin pour les compilations cible.

Questions :
- Quelqu’un a déjà testé le craoss-plateform dans cette configuration

Vos avis m’aideront à mieux m’y retrouver. Quitte à me lancer dans une techno et à apprendre quelque chose, autant que cela soit pérenne dans le temps. Je n’aurais pas le temps de développer à plein temps avec maitrise de 5-6 langages et autant d’autres technos.

Merci pour avoir lu ce pavé indigeste 