-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thierry Leurent wrote: ... > Une des solutions présentées. > Serveur Oracle pour la base, .NET 2 (C#) + Crystal Report pour la couche > application et la couche client, Word/VBA pour le rapport.
Euh... je cite: "Ma boite n'est pas sensible à l'Open-Source, mais devient sensible aux standards et à la portabilité Elle a eu de mauvaises expériences avec du tout Microsoft." Donc on prend .NET (MS), Crystal Reports (Windows), Word/VBA (MS). Logique ;) > Nous avons rencontré la société qui propose cette solution. > Quand, j'ai parlé de portabilité Ils ont parlé de Java et ont justifié le > choix de .NET par rapport à Java en indiquant que Java était plus lourd, > moins aisé pour un développement rapide et surtout moins stable dans le > temps. > Ils ont parlé que d'un JDK/JRE à un autre des fonctions disparaissaient ou > que > les appels changeaient. Donc une application développée avec le JDK 1.3 ne > pourrait pas être utilisée avec le JDK 1.5. Quoi ? HAHAHAAHAAAAAAAHAHAHAHAA MDR C'est une blague ? C'est quoi ces clowns ? Bon, alors: 1) Java "plus lourd" que .NET Ca veut dire quoi ça ? - - .NET et toute sa communauté n'a pour l'instant _aucune_ solution pour tout un tas de problèmes qu'ils vont encore rencontrer dès qu'ils vont développer des applications un chouya plus complexes (mappings ORM, identité d'objets quand on fait du remoting, intégration de systèmes "legacy", clustering HA, ...) - - je veux bien que Ruby ou Python soient "moins lourds" que Java puisqu'ils ne proposent des solutions que pour des problèmes moins complexes, mais .NET... euh... n'importe quoi Si c'est une question de performances, c'est ridicule: Java sur le serveur est extrêmement performant, d'une part par la JVM elle-même (hotspot compiler, garbage collection) qui a 8 ans d'avance sur celle de .NET, d'autre part parce que des applications "enterprise" sont développées depuis des années avec Java et qu'il y a des solutions, produits et standards permettant des approches hautes performances. Certes, Swing est assez "lent" sur le client, mais pour ça c'est portable, le modèle de développement est très bon (MVC) et solide. Franchement, on fait beaucoup d'applications client Swing complexe (entre 50 et 400 utilisateurs en même temps) + conteneur EJB et ça fonctionne très bien, aucun client ne s'est jamais plaint (beaucoup de clients banques, télécoms, ...). Note qu'on fait aussi des applications web et j'en ai fait quelques-unes d'assez complexes dans mon temps libre (http://packman.links2linux.org). C'est bien aussi mais c'est plus compliqué et prends plus de temps à développer (complètement stateless, portabilité au niveau des navigateurs). 2) Java moins aisé pour un développement rapide En gros, ils te disent qu'ils développent comme des m..... Quand tu sais ce que tu fais et que tu écris quelque chose de solide, peu importe Java, Ruby, .NET, Python, C++, ... (mais quand même pas visual basic). 3) moins stable dans le temps Alors là c'est le pompon. C'est exactement le contraire. .NET 2.0 est totalement incompatible avec .NET 1.x Java 6 est "upwards compatible" avec 1.1, càd que du code écrit pour 1.1 fonctionne encore avec 6 (juste quelques petites différences avec Swing à partir de 1.3 et 1.4 côté client). C'est justement un des grands avantages de Java, la compatibilité. JEE 5 est compatible avec J2EE 1.3 et 1.4. Évidemment, si tu écris du code Java qui utilise les nouvelles fonctionnalités de Java 5 (generics, annotations, autoboxing), ça ne fonctionnera pas sur 1.4 ou 1.3. C'est un choix à faire lors du développement (ou du cahier de charge). Par contre, écrit avec Java 5, ça fonctionnera avec Java 6 et 7 et ... Et tu peux très bien écrire des applications Java en utilisant que les fonctionnalités Java 1.4 (même si tu utilises une JVM 5). Dans ce cas, ça fonctionne sur 1.4, 5, 6, ... C'est pas si compliqué, juste une option de configuration dans Eclipse ;) Pareil avec JEE. "Ils ont parlé que d'un JDK/JRE à un autre des fonctions disparaissaient ou que les appels changeaient. Donc une application développée avec le JDK 1.3 ne pourrait pas être utilisée avec le JDK 1.5." Complètement faux, mensonge ou incompétence pure et simple. > Quand j'ai parlé de technologies "WEB", j'ai eu > - Un "c'est trop compliqué il faut développer pour chaque browser". Pour les > technologies web en général. IE occupant 90 % des parts du marché (C'est pas > > les derniers chiffres dont je me rappels mais bon) > - Un "C'est du bête HTML", pas convivial. Pour les normes W3C. > - Un "C'est volatile (ça change tous 12 à 18 mois). AJAX !!! Berrrrrk !!!! > Vous voulez développer une application critique en AJAX ????? Mais vous êtes > fou !!!" Quand j'ai parlé d'AJAX. Eh bein. > Voici mes conclusions qui demandent vos commentaires et retours > d'expériences : > - Vu la complexité des "calculs" et des contrôles (Calculs basics et > intégrité > référentielle), Je placerais tous cela au niveau DB. Donc la partie > application/client fait des appels à la DB et des "impressions". Moui. Pour l'intégrité référentielle, oui, forcément dans la DB. Mais des "stored procedures"... Pas une bonne idée à mon avis, parce que tu te lies à une base de données bien spécifique (p.ex. PL/SQL Oracle, si tu passes à une autre DB (p.ex. PostgreSQL ou DB2), oublie, faudra ré-écrire beaucoup). Plutôt faire ça dans le code applicatif. Les stored procedures, c'est surtout intéressant pour optimiser (en termes de performances). Dans ce cas, tu as sûrement ton architecture bien propre, avec un DAO qui fait abstraction de la base de données et de comment certaines données sont tirées de la DB (ou autre chose), donc il suffit de modifier le DAO et tout le reste de l'application reste pareil. (enfin, ça, c'est une architecture propre comme un le fait classiquement avec Java, certainement pas le genre de choses que les développeurs de cette boîte connaissent) > - .NET 2 n'est pas portable enfin pas encore son support dans Mono est prévu > pour la fin de l'année. Puis, il faut voir les bibliothèques utilisées. .NET == portabilité 0 Le "standard" .NET est encore en mouvement, et l'est probablement encore pour un bon moment. Comme déjà dit, .NET 2 est incompatible avec .NET 1.x (et pas qu'un peu). Et puis que .NET soit un standard... ouais, sur papier ou dans la propagande MS, mais dans la réalité... La CLI .NET (équivalent de la JVM Java) et C# sont effectivement dans le standard ECMA, mais - - dans les faits, le "standard" .NET est contrôlé à 100% par MS - - d'autres composants nécessaires au développement d'une application ne sont pas dans le standard ECMA, que ce soit ASP.NET, les librairies de développement d'applications graphiques, etc... Java n'est pas uniquement contrôlé par Sun, il y a le JCP (Java Community Process). Certes, il n'y a pas beaucoup d'alternatives à la JVM de Sun (quoique, IBM et BEA fonctionnent très bien, et Kaffee et autres JVM libres sont en cours de développement), mais - - JDBC est un standard - - JEE est un standard (JEE 5 contient même un standard pour les ORMs: JPA (Java Persistence API)) - - Servlet et JSP sont des standards - - Swing est un standard etc... Avec .NET, tu n'as que la CLI et C# qui sont standardisés (et encore, ça change tout le temps pour l'instant). > - .NET est plus stable au niveau version que Java. Cela m'étonne mais je ne > connais pas les deux mondes donc je n'ai pas d'expérience concrète et vous ? Ridicule, c'est exactement le contraire. C'est comme s'ils te disaient que Linux est plus propriétaire que Windows. > - .NET est plus souple que Java. Confirmation ? "souple"... là je dirais également que c'est le contraire, parce que Java contient un très grand nombre de standards et différentes implémentations (JBoss, Weblogic, Websphere, Glassfish, ......, Hibernate, .....) Au niveau du langage, C# a quelques trucs pas mal au niveau du "syntactic sugar" mais d'autres qui sont plutôt... bizarres (pas de checked exceptions). > - Crystal Report est l'idéal pour générer des documents à partir de base de > données et modèles. Oui. Mais dans ce cas, tu es lié à Crystal Reports. http://jasperforge.org/sf/projects/jasperreports > - Le Web, c'est pas si pauvre que ça au niveau présentation. Même sans AJAX, > au pire on adapte un peu le code généré en fonction du browser (Transparence > des PNG par exemple). Connaissez-vous des sociétés qui fuient AJAX ? Moui. Là, faut voir. AJAX c'est beaucoup de hype, c'est surtout pour que des consultants vendent beaucoup de livres et se fassent de l'argent dans des projets (quoique, "SOA" est encore bien pire à ce niveau-là). Certes, AJAX ça peut donner des applications web très conviviales et très intéressantes (Flickr, Basecamp, ...), mais c'est loin d'être une technologie mature. Et le coût de développement d'une application web est toujours plus élevé que pour une application "rich client" (p.ex. Swing), que tu utilises AJAX ou pas. On en a déjà fait aussi, c'est pas la panacée, mais dans certains cas de figure c'est très intéressant. Ca dépend vraiment de l'environnement, des contraintes, de la complexité de l'application. > - Un serveur applicatif engendrerait des coûts plus élevés au niveau licences > (CR par exemple). Il y a plusieurs conteneurs libres et gratuits (et très très bons ;)) pour Java: - - http://www.jboss.org/products/jbossas - - https://glassfish.dev.java.net/ - - http://jonas.objectweb.org/ - - http://tomcat.apache.org/ - - http://jetty.mortbay.org/ Pour Crystal Reports: http://jasperforge.org/sf/projects/jasperreports > Questions subsidiaires ? > - Quelqu'un connaît-il Microsoft Reporting Service ? Non merci. > - Existe-t-il un "Crystal Report Like" Open-Source ? Pas forcement compatible. http://jasperforge.org/sf/projects/jasperreports > Que pensez-vous de la proposition suivante pour la couche application? > PHP 5 générant des pages xhtml et des css. - - clients web Ca dépend vraiment des fonctionnalités à implémenter. Si tu as une couche de représentation assez complexe (p.ex. call center), j'irais plutôt dans la direction des clients riches (p.ex. Swing). Au niveau du "deployment" (qui est le grand avantage des applications web), avec Java tu as Web Start (http://java.sun.com/products/javawebstart/) Sinon, si la représentation web est suffisante, pourquoi pas. PHP est quand même un langage simple à utiliser mais extrêmement limité pour le développement d'une application solide (et crois-moi, j'en ai fait du PHP). A mon avis, PHP c'est bon pour faire une dizaine des pages web au maximum, mais pour quelque chose de plus complexe ou plus critique, je prendrais Java. > PHP 5 Triturant du XML-MSOffice pour le rapport normalement en .doc. > Cette solution pose au moins deux problèmes : > Comment lancer Word depuis PHP. > Comment construire facilement de nouveaux rapports. http://jakarta.apache.org/poi/index.html http://radio.javaranch.com/val/2004/10/16/1097909528000.html "Google is your friend" ;) Et puis, pour lancer word à partir d'une application web, il suffit de mettre le MIME type correctement ("application/msword" ou un truc du genre). On a des équipes de projet qui ont déjà fait ça pour Excel, pas vraiment un problème. Evidemment, si Word supportait déjà le format ODF, ce serait bien plus simple pour générer les documents ;) - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFOhoKr3NMWliFcXcRAqJ9AKCyC3F6DqSk8aXWFS6gkOUN7v/+CwCfVx7O JGRTY2/XLetc0gp23JVQPV4= =Sj9R -----END PGP SIGNATURE----- _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
