Discussion :

[maestro1303]

Bonjour à tous
Je demande aux professionnels leur avis sur le sujet qui suit : avec des amis nous avions développé un outil pour une application chez un industriel avec du VBA Excel et des tests du produit ont été effectués et se sont avérés très concluants. Seulement cette application a été développée de manière pas très professionnelle par des gens qui ne sont pas spécialistes du GL. Mais puisque le principe de ce produit a eu de grands succès lors de sa présentation, nous voulons à présent reprendre son développement avec des langages professionnels.
Est-ce que quelqu’un peut donner des conseils dans ce sens ?
Merci infiniment

[moldavi]

Bonjour.

Si vous voulez des conseils sur le langage à choisir, il nous faudra plus d'information sur le projet en lui-même.

[maestro1303]

Bonsoir moldavi,
Tout d'abord je te remercie de cette réponse rapide.

Cette application a été développée sur VBA Excel car elle prend en entrée des feuilles Excel de différents formats :
1) Elle uniformise les écritures dans toutes les feuilles pour pouvoir effectuer des calculs et des comparaisons entre les feuilles plus tard en compilant toutes les feuilles en une seule
2) Elle prend alors une deuxième entrée d'un autre genre: les données existantes dans le système cible qui est, disons-le tout de suite, un switch class4 téléphonique.
....
3)Avec les données en 1 et 2 elle produit un fichier texte dans un langage compréhensible par le switch qui ne sont ni plus ni moins que des directives de routage (personnalisées selon la marque du switch cible).

Voici en gros ce que fait cet outil.


Merci d'avance.

[Invité]

Bonjour

Personnellement je te dirais de passer par VB.net, c'est ce qui t'approchera le plus du langage VBA (certaines syntaxe comme des boucles sont similaires), et tu y retrouveras vite tes petits.

Philippe

[maestro1303]

Bonjour Mr Philippe,
Je te remercie c'est en effet tout à fait logique.

Ce produit fonctionne depuis 2011 de la manière que j'ai expliquée plus haut avec une certaine lourdeur et si je ne pense à lui donner une nouvelle vie c'est essentiellement pour deux raisons:
-rendre son utilisation plus facile: c'est à dire rendre la génération du fichier de Mass Provisionning moins coûteuse
-nous allons peut-être disposer de moyens financiers pour aider à ces développements(recruter des professionnels du développement, disposer de matériels pour les tests...).


Merci de vos suggestions et conseils.

[moldavi]

Bonjour.

Je rejoins Philippe JOCHMANS sur le choix de VB.net pour sa proximité avec le VBA, mais je conseillerai C# (c'est juste un avis personnel, parce que les deux sont adaptés).

La partie délicate sera de faire de l'interop avec Excel, je pense. J'ai toujours trouvé que c'était une sinécure en C++ natif. Mais je sais que le framework .net propose des outils pour cela. Je ne sais pas ce que ça vaut aujourd'hui. Il y a des chances pour que le framework d'aujourd'hui permette une manipulation aisée des feuilles Excell.

Un point à vérifier selon moi, parce que le VBA est peut-être finalement plus adapté et plus simple pour ce genre de manipulation.

[maestro1303]

Merci beaucoup encore une fois,
De mémoire VB,C++,C Sharp sont contenus dans la plateforme .NET(ceci me rappelle des souvenir lointain).
Est ce que le framework est gratuit. ?.


Maintenant que nous avons cette information, nous pouvons commencer les autres étapes c'est à dire;

• Recrutement de 2 développeurs
• Acquisition du matériel de développement et de test(Ordinateur comme les switches
• Recrutement d'un technico commercial pour faire de la Pub du produit (après qu'il soit relooké bien sûr )chez les opérateurs télécoms.

Auriez vous une critique par rapport à cette démarche et ordonnancement de ses différentes tâches?


Merci

[moldavi]

Bonjour.

Est ce que le framework est gratuit. ?.

Oui. Par contre si vous recrutez 2 dev, ils vont peut-être vous demander d'acheter la licence Visual Studio.

Sur la démarche avez-vous fait une étude de marché ? En gros est-ce que le produit va se vendre. Et la vente/maintenance de ce produit permettra-t-elle de soutenir tous les charges (niveau financier).

[scandinave]

Moi je me tournerais du coté de talend open studio. Si j'ai bien compris ton appli, elle aggrège des données provenant de différentes sources, les analisent, les nétoient éventullement et produit une fichier en sortie? Talend est spécialisé pour ce genre de chose, génère du code java et ne nécéssite pas de connaissance de dev très poussées. Très utile si vous avez des délais serrés.

[Mat.M]

Mais puisque le principe de ce produit a eu de grands succès lors de sa présentation, nous voulons à présent reprendre son développement avec des langages professionnels.
Est-ce que quelqu’un peut donner des conseils dans ce sens ?
Merci infiniment

si ça tourne très bien avec VBA il n'y a pas de raison de passer à autre chose..
sauf s'il y a des contraintes et encore...
VBA est aussi performant sinon plus que .NET...
et on peut très bien faire de la programmation objet minimale et modulaire avec VBA avec des modules de classe.
L'avantage de VBA c'est que tout est intégré; avec un environnement de développement on risque de se disperser avec des composants tierces..
qui dit se disperser dans un projet informatique dit construire une usine-à-gaz et qui dit usine-à-gaz dit projet Titanic

[I_Pnose]

VBA est aussi performant sinon plus que .NET...

VBA sera plus performant sur les interractions avec Excel, certes (et encore les pertes de performance dues à l'interop depuis .Net sont négligeables), mais s'il y a des traitements à faire en dehors de ces interractions, il n'y a pas photo ; les perfs de .Net sont très loin devant les perfs de VBA. Après c'est sur que si le portage en vb.net/C# de l'application est juste là pour faire des opérations sur des feuilles Excel (y compris les phases de calculs) le développement n'a que peu d'intérêt.

La partie délicate sera de faire de l'interop avec Excel, je pense. J'ai toujours trouvé que c'était une sinécure en C++ natif. Mais je sais que le framework .net propose des outils pour cela. Je ne sais pas ce que ça vaut aujourd'hui. Il y a des chances pour que le framework d'aujourd'hui permette une manipulation aisée des feuilles Excell.

En .Net il n'y a aucune difficutlté à faire de l'interop Excel, Word, etc... Une petite référence COM et le tour est joué.

De mémoire VB,C++,C Sharp sont contenus dans la plateforme .NET

Attention à ne pas faire l'amalgame entre C++/CLI (dit managé, intégré à la plateforme .Net) et le C++ dit natif (celui dont fait allusion moldavi).

[moldavi]

Bonjour I_Pnose.

En .Net il n'y a aucune difficutlté à faire de l'interop Excel, Word, etc... Une petite référence COM et le tour est joué.

Oui. Le problème, même en C++ natif, n'est pas la référence COM. C'est l'utilisation qui vient après. Je suis d'accord, une petite référence, mais le tour n'est pas joué... En C++ natif j'ai pas mal bataillé avec l'interop Excell alors que j'utilise DirectX, DirectShow et d'autres APIs sensées être Dark.

Maintenant, Microsoft a largement amélioré sa documentation. Il y a beaucoup de samples en plus des forums. Et comme je sais que Microsoft chouchoute pas mal C#, c'est la raison pour laquelle j'ai avancé l'idée que pour de l'interop C#/Excell, cela doit rouler effectivement.

[I_Pnose]

Je me doute bien que faire la référence à l’objet COM n’est pas le plus compliqué à réaliser dans l’affaire ^^. Je n’ai jamais fait d’interop Excel en C++ natif je n’ai donc pas de point de comparaison à fournir, cela dit je maintiens ce que je dis ; une fois la référence faite il n’y a pas réellement de difficulté (à fortiori en lisant quelques tutos à droite à gauche).

A titre d’exemple les 5 lignes de code ci-dessous permettent de remplir une plage de cellules, et le reste des opérations est du même acabit (comme je l’ai dit, j’ignore si c’est plus laborieux à réaliser en C++ natif) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
var excel       = new Application();
var workbook    = excel.Workbooks.Add(XlWBATemplate.xlWBATWorksheet);
var worksheet   = workbook.Worksheets[1] as Worksheet;
var range       = worksheet.get_Range("A1", "A5");

range.Value2    = 12;

[moldavi]

Re.

Oui comme cela, ça me paraît sympa à utiliser.

Ici le genre de code qu'il fallait pratiquer en C++ natif :

http://support.microsoft.com/kb/216686/fr

A l'époque, il fallait être un sacré guerrier de la programmation COM... Et je ne l'étais pas. Et pourtant je me débroullais pas trop mal avec d'autres API du même genre.

[Mat.M]

A l'époque, il fallait être un sacré guerrier de la programmation COM... Et je ne l'étais pas. Et pourtant je me débroullais pas trop mal avec d'autres API du même genre.

que COM soit très compliqué voire impossible à programmer, je pense que c'est une volonté délibérée de Microsoft de rendre cette technologie très compliquée( désolé de sortir du sujet..).
De toute façon sauf pour les logiciels Microsoft en interne, maintenant COM n'a plus grand intérêt étant donné qu'il y a .NET

[moldavi]

Bonjour Mat.M

que COM soit très compliqué voire impossible à programmer, je pense que c'est une volonté délibérée de Microsoft de rendre cette technologie très compliquée( désolé de sortir du sujet..).

Effectivement nous sommes hors sujet, mais je réponds.

COM n'est pas compliqué par une volonté délibérée de Microsoft, mais parce que COM gère des aspects inter-threads et inter-process. Et ça c'est compliqué.

Ce que je reproche à l'interop Excell en natif, c'est sa syntaxe barbare, trop proche de COM origine.

De toute façon sauf pour les logiciels Microsoft en interne, maintenant COM n'a plus grand intérêt étant donné qu'il y a .NET

.NET utilise COM pour le GDI, pour DirectX, pour MediaFoundation, etc... Je ne vais pas faire la liste, elle serait trop longue à chercher...

En fait .NET est puissant, parce qu'il utilise des services en C++ natif avec la techno COM.

COM est la pierre angulaire de l'interop sous Windows. C'est du plus grand intérêt pour Windows actuellement.

[Mat.M]

bonjour Moldavi

COM n'est pas compliqué par une volonté délibérée de Microsoft, mais parce que COM gère des aspects inter-threads et inter-process. Et ça c'est compliqué.
Ce que je reproche à l'interop Excell en natif, c'est sa syntaxe barbare, trop proche de COM origine.

d'accord mais il y a un peu de la contradiction ; qui dit syntaxe barbare dit technologie très compliquée, qui est difficilement acessible aux débutants plus que ne le sont .NET ou Java..
Mais je suis persuadé que c'est volontairement fait exprès..
parce que Word, Excel et sans doute Access c'est bâti à plus de 90% d'objets Component Object Model sauf l'interface utilisateur.
Et je soupçonne Microsoft d'avoir fait ça pour éviter que toute entreprise ou tout petit malin redéveloppe un tableur ou un traitement de texte dans son coin,le commercialise et concurrence Word ou Excel
autrement dit si quiconque se lance dans le projet de concurrencer Word par exemple il faut vraiment être très fort.