Bonjour,
Depuis pas mal de temps je suis un projet d'une application e-commerce (OsCommerce mais largement mieux - C'est pas de la prétention c'est que j'en suis sur ).  
J'ai presque finie le projet au niveau base de données qui m'a pris pas mal de mois car je ne voulais pas négliger cette partie là. En effet, je travail avec Mysql5 (pour un premier temps) et exploite au maximum ses nouvelles fonctionnalités. Moteur InnoDb + Archive. Trigger, Vue, tout fonctionne quasiment avec des procédures stocké, etc.
Maintenent, je vais bientôt commencé à coder l'application. Lorsque j'ai commencé à étudier la partie objet j'ai finalement remarqué que j'ai l'équivalent d'une framework de mon application car tout est entièrement en objet. L'application sera prévus en PHP5 depuis longtemps pour des raisons que tous le monde connait.  
Maintenant, je pose la question si c'est judicieux de le faire aussi en C#.  
Pourquoi ? Depuis longtemps je suis attiré par ce language et ça aurait un bon moyen de continuer à apprendre. J'ai déjà fait quelques petite applications dessus, donc l'univers me parait pas complétement inconnu. Ma question, est de savoir si c'est judicieux de monter l'application en parrallele en sachant que php sera prioritaire et que pour c# ça sera au final q'une dll donc pas d'interface graphique? Est ce que je pars dans un mauvais délire ?
Merci

Salut,
 
Judicieux, pas judicieux, ça dépends surtout de la cible et de ce que tu veux faire.
 
Point de vue déploiement, évidement le PHP sera plus aisé, puisqu'on le trouve sur presque tous les hébergeurs, à des prix défiant toute concurrence, ce qui n'est pas le cas de C#.
 
Ensuite, pour un serveur dédié, il faut garder en tête que MONO existe, et pour l'avoir tester (très en vitesse) il marche plutôt bien.
Donc d'un point de vue portabilité, je te conseille, si tu fais le site aussi en C#, de le faire tourner avec MONO : effectivement, ce dernier n'implémente pas correctement l'ensemble du Framework de Microsoft, donc il faut faire attention aux objets utilisés, et il sera trop tard une fois le site terminé pour se dire "tiens, et si j'essayais de le faire tourner sous Mono ?".
 
Maintenant, point de vue cible, un certain nombre d'entreprises disposent de fermes de serveurs web, avec des administrateurs compétents pour les entretenir. Celles qui auront choisi C# seront bien évidement hostile à une solution PHP, puisque personne ne saura entretenir le serveur. C'est donc un choix qui peut permettre l'ouverture à de nouvelles cibles. Ceci dit, c'est certainement peu significatif.
 
Par contre, niveau "formation", évidement ce sera intéressant pour toi. A titre perso comme professionel.
 
Par contre, je ne pige pas ton histoire de "ça va être une DLL sans interface graphique" () Comment ça ? En C# tu peux parfaitement faire un site web.
 
Enfin, pour le fun, tu peux t'amuser à combiner les deux (par contre, tu perds tout espoir de trouver une solution d'hébergement simple) : un web service en C# qui est utilisé par une front-end en PHP
Pour le coup, ce sera uniquement formateur, aucune chance ou presque de trouver une personne prête à déployer une telle solution
 
Au final, je te conseille TRES FORTEMENT de clôner ta base sous Oracle XE, MS SQL Express et PostGreSQL. Effectivement, là par contre tu t'ouvres énormément de portes pour d'éventuels clients qui veulent une solution hébergée en interne : s'ils ont un DBA, il préfèrera utiliser le SGBD qu'il a l'habitude d'utiliser. Niveau fonctionnalités, tous les 4 sont "relativement" similaires, donc mise à part quelques points plus chiants que d'autres, tu devrais t'en tirer sans trop de difficultés.

Ben, une heure après avoir écris le topic je me suis dit. Une DLL ? Oui mais avec quoi je vais interfacer/administrer les informations ? . Effectivement, je vais pas faire une interface en php pour une dll en .net et comme tu le dis, c'est pas facile de trouver un hebergeur pour ça.  
J'ai pas de réelle cible envisager pour le C#. Car dans ce domaine, l'open source n'est pas forcement bien vu. Généralement, c'est des entreprises qu'il peuvent mettre les moyens pour avoir un support derriere.
Après, j'avous que c'est plus pour me former dans ce domaine qu'en faire une reelle application vu la porté que cela va avoir.  
 
Concernant les autres SGBD ça sera l'une des phases de l'évolution de l'application mais seulement qu'après la version mysql sera mure . Par contre j'avais dans l'idée que pour l'instant ça sera SQLServer et peut être POSTGreSQL mais je me rappelle pas s'il est possible de faire des procédures stockées avec.  
Merci du conseille

MSSQL et Postgre permettent les procédures stockées. Par contre, merci d'éviter Oracle

MSSQL oui j'étais sur à 110% mais moin pour Postgre. Pourquoi je devrais éviter Oracle? Je sais que c'est du lourd et perso j'étais pas chaud pour jouer avec .

si t'as envie de jouer à la chasse aux ORA machin qui pètent à tout bout de champ sans la moindre raison logique, alors fonce, moi j'ai donné (et je continue à donner)

C'est vrai qu'Oracle ça en a la couleur, l'odeur, et le goût. Une bonne bouse de rhinocéros bien fraîche, avec des petits bouts de brindilles épineuses qui croustillent.
 
Mais bon, c'est aussi le plus répendu dans les entreprises, donc bon... faut faire avec.

OKk, je comprend. Mais bon si l'entreprise à les moyens de se payer un Oracle je vois pas la raison pour laquelle il voudrait se payer une application libre fait par un petit développeur inconnue  
Après, si l'application prend du poid avec le temps, ce dont je souhaite, pourquoi pas.

Oracle, O désespoir...;