C# versus Java

sauf que le SQL, c'est relativement standard ;)

Pour comparer les choses comparables, ce n'est pas la même chose de configurer et d'administrer un serveur oracle et un serveur "SQL server". Tes compétence SQL server, elle ne te serviront à rien quand tu devra évaluer les conséquences des 5000 options que te proposent oracle à l'installation. Et je peux te dire par expérience, une seule option mal choisie peut entrainer des effets néfastes à long terme sur la database. Pas pour rien que pour l'installation on fait appel à des gens qui font que ca tous les jour. La dernière qu'on a installée ici a mis des semaines à être configurée.


PS: et si t'as pas 20To de données, tu utilise pas du oracle, c'est trop cher :lol:

Citation:

---

Envoyé par Laurent Jordi

De ce que j'ai vu du java, je ne vois pas vraiment de différence avec le c# pour moi la différence réside dans le Framework et dans les outils d'intégration et de débogage.

---

Ce n'est pas une maigre différence, je suis passé de .Net à Java suite à un changement de job. Bien qu'ayant déjà certaines connaissances de java, j'ai quand même galéré pour m'habituer aux frameworks, à la toolchain etc...

En .net, pour une application web type, ton choix par défaut c'est Asp.net. Tout ce que tu trouves comme documentation c'est IIS, vs2008 et Asp.net, il est donc très facile de transposer tout ça pour que ce la corresponde à ton problème.
En java, c'est beaucoup moins straightforward car c'est beaucoup plus la jungle. Il existe plusieurs serveurs d'applications, des dizaines de frameworks de présentation pour le web, ils sont plus ou moins bien pris en charge par les IDE, plus ou moins difficile à mettre en oeuvre et à configurer et ils s'empilent généralement plus ou moins bien sur d'autres frameworks censés assurer la couche métier/persistence.

Et là le problème, c'est qu'on trouve de tout, donc trouver ce qui te convient est plus difficile et tu n'es pas à l'abri de te vautrer dans tes choix. Tu parlais de webservices, c'est un bel exemple, là aussi, sous .Net tu es facilement guidé par ton IDE vers le standard et tu arrives vite à un résultat, sous java ce sera de nouveau la croix et la bannière pour trouver un produit qui fait ce que tu cherches comme tu le souhaites. Les premiers sur lesquels on tombe sont souvent des mastodontes certes puissants mais très chiants à configurer et à mettre en oeuvre, il faut savoir trier et trouver le truc qui va à l'essentiel.

Perso j'ai plusieurs fois abandonné des frameworks car trop pénibles à mettre en oeuvre, trop mal documentés ou ridiculement complexes par rapport à ce que je souhaitai faire.

C'est bien ça le problème.
Les experts fonctionnels qui spécifient des applications sans connaitre la technique, les architectes qui conçoivent sans considérer la techno...
Et après on dit : Ah c'est un plat de spaghetti, et ça coute super cher.

Heureusement pour nous que les architectes du batiment comprennent tous les matériaux qu'ils utilisent et que les bureaux d'étude disposent des moyens de vérifier la viabilité des architectures.
Si on construisait les immeuble comme on conçoit l'informatique aujourd'hui...
Vous imaginez un expert en plomberie ne pas comprendre la soudure ? Un artiste ne pas faire la différence entre la peinture à l'huile et la sanguine ?

Je suis outré de lire certaines choses. Un architecte qui dit qu'il peut construire une application sans considérer la techno il mérite surtout de prendre la porte.
Et pourquoi ? Parce que le socle technologique est structurant. Quand on décide d'utiliser un SGBD, il faut comprendre le SGBD, suivre la norme SQL, penser relationnel. Ca ne s'invente pas du jour au lendemain et ce n'est pas qu'un choix technique sans conséquence.
Une architecture multitenant ça ne se résoud pas avec "on va rajouter un classe d'identification et du sharding".
Utiliser du calcul GPU ça se pense, c'est structurant. Designer une API viable, c'est basé sur les possibilités du langage et notamment sur la preuve et la fiabilité de l'API.
Le banc de test, l'usine logicielle...Tout ça c'est mineur ?
Les charges, les modes d'utilisation.

Ah oui, de façon agnostique je peux dire :
Il faudrait une application qui fasse ce qu'il faut mais qui puisse faire plus et qui puisse être utilisée sur le web, sur un pc, un mac, un iphone et un blackberry, que tous les traitements soient rapides et que tous les traitements soient audités et qu'on garde l'historique de tout ce qui est fait, et qui le nombre d'utilisateurs soit multiplié par 1000 ça marche encore sans changement.

Super.

Quand j'étais petit, j'écrivais des choses agnostiques de la réalité pour noel.

Moi j'ai pour principe de dire : un sujet que je comprends, c'est un sujet que je peux développer. Disons simplement qu'il existe des sujets triviaux où peu de questions existent, mais pas toujours.

Ca mériterait de créer un nouveau débat sur le métier d'architecte :

"Architecte : quelles sont les compétences techniques requises ?"

:D

http://i43.tinypic.com/6rsp47.jpg

Y'en a qu'on de la chance, l'architecture est conçue par des architectes(même mauvais). Ici, elle est conçue par la MOA, qui assigne les morceaux à differentes technos en fonction du cout, et ne comprend rien à la tuyauterie. Alors donc, on a un progiciel qui génére des fichiers de campagnes marketing sous UNIX(jusque là normal), puis un ETL maison sous UNIX les retrafique pour changer le format, puis c'est transféré sous COBOL pour un enrichissement, puis ça revient sous UNIX pour être intégré à l'appli transactionelle Java.

Pourquoi? Parceque pour la partie enrichissement, le Cobol était moins cher à la réalisation. Et comme il y a déjà des traitements cobol qui existent(non réutilisables), il faut une bidouille ETL pour mettre à l'ancien format cobol(alors que le nouveau format aurait parfaitement convenu). Et on revient à la fin vers java parceque c'est eux la cible. Et si on propose des améliorations, elles sont mises à la poubelle avant examen.

Alors que les gens du java ont, à disposition, tout ce qu'il faut pour enrichir les données. Ils auraient peut-être couté un poil plus cher que nous cobolistes, mais ça aurait permis de zapper l'ETL, et surtout de ramener les couts de maintenance à un niveau acceptable.

Tout ça pour dire qu'effectivement, comparer les langages, c'est bien difficille, parceque le feed-back qu'on peut en avoir est fortement altéré par des raisons extérieures. Chez un autre client, j'ai vu un collègue Javaïste(ça se dit?) ne jamais éteindre son poste parceque recharger le projet sous Eclipse prenait 4 heures(et 1 heure après avoir enfin reçu un PC supermoderne, au bout de 2 ans d'attente). Fatalement, ça me laisse un a priori défavorable sur java, alors que c'est juste lié à une architecture abérrante - un seul projet monobloc pour une appli monstre.

Bon... Je crois que pour le moment, je vais rester en .net mais j'ai quand même envie de me former à java.

Je suis quasiment certain de pouvoir transposer mes tips & tricks de .net en java.

J'ajoute que comme je maîtrise pas mal les poco t4, j'ai très envie de modifier mon générateur de couches pour qu'il puisse aussi bien générer du java que du c#.

Pour information, j'ai créé une structure de couches qui génère automatiquement :
La couche domain
La couche datarepository
La couche Context
et pour les amoureux du MVC3, j'ai même généré la couche Models avec les dataannotations localizées.
Prochaine étape génération des fichiers de ressources automatiquement aussi.

C'est tellement puissant qu'en partant d'AMC Designer, je génère une base SQL Server, je régénère l'EDMX et les Pocos et hop, je n'ai plus qu'à travailler ma couche business (jusque là, rien d'impressionnant).
J'ai fait le test suivant, je pars du même modèle de base dans amc designer, je change le sgbd de sortie, je génère la base en MySQL, je modifie le connecteur entity framework, je pointe sur la base my sql et,
SANS AUCUNE MODIFICATION DE CODE, l'application a migrée de SQL Server à MySQL... Ouille bobo à Microsoft...

Qu'en pensez-vous ?

++

Laurent

je connais pas .net, en java j'ai toujours eu des applications indépendantes dans la DB, donc en fait je vois pas trop l'utilité de porter ton générateur en java :aie:

Là, je me permets de dire que tu fais preuve de mauvaise foi.

Une application multicouches (pas hello world) vraiment indépendante de la db, je n'y crois pas il y a toujours une dépendance, ne serait-ce qu'au niveau de la couche business.
Le seul contre exemple en .net est une application de type Application Web Dynamic Data ASP.net Entities qui ne permet d'avoir que le back office de n'importe quelle base. C'est bien indépendant de la structure de la base à condition que la base soit correctement construite et ça ne génère pas les IHM Business (ce qui est quand même une bonne chose pour notre métier).

Etant toujours curieux de monter en compétence, si tu as un exemple, je veux bien regarder...

++

Laurent

Tu fais du code SQL conforme à la norme du côté client de ton sgdb et dans les cas particuliers où tu as besoin d'utiliser les particularités de ton sgdb, tu fais des procédures stockées, des vues et autres trucs de ce style...

Au final, t'as un truc qui est, côté client, indépendant de la base...

Enfin, je vois pas trop pourquoi ta couche business devrait être dépendante du sgdb... Logiquement, elle n'a même pas connaissance de la couche d'accès aux données qui pilote le sgdb, alors...

Peut-être que je pige pas ce que tu dis.

Citation:

---

Envoyé par Laurent Jordi

Là, je me permets de dire que tu fais preuve de mauvaise foi.

Une application multicouches (pas hello world) vraiment indépendante de la db, je n'y crois pas il y a toujours une dépendance, ne serait-ce qu'au niveau de la couche business.

---

Hum... Normalement il y a très peu de dépendances entre la couche "purement" business et la BdD. La seule dépendance est dans la DataSource, ou a la limite dans le DAO (si on se passe d'une DataSource et qu'on gère soi-même l'accès aux données).

http://java.sun.com/blueprints/corej...igure09_02.jpg

:arrow: http://java.sun.com/blueprints/corej...rns/index.html

;)

Ce que je veux dire c'est qu'il y a forcément un moment où tu as des champs spécifiques (genre la couleur d'un fond d'un écran, une langue, les membres d'une formule). Si tu fais une base de données pour gérer de ventes de pizza tu ne pourras pas faire fonctionner un logiciel de calcul financier avec.

C'est pourquoi j'ai assez tendance à m'appuyer sur des générateurs de code plutôt que d'abuser des outils génériques qui génèrent des générateurs de code indépendants de la génération de la structure générique qui finit par te faire oublier que le programme que tu crée est fait pour résoudre une problématique métier et non pour faire un comparo entre la culture technique d'un développeur par rapport à celle d'un autre.

Concernant le schéma que tu présentes, je ne doute pas de sa généricité ou de son efficacité voir même d'une meilleure efficacité de ce que je mets en oeuvre.

Quand on dit "dépendance de la abse de donnée" on parle du sgbd, pas de la structure de la base de donnée en elle meme.

Citation:

---

Envoyé par Laurent Jordi

Ce que je veux dire c'est qu'il y a forcément un moment où tu as des champs spécifiques (genre la couleur d'un fond d'un écran, une langue, les membres d'une formule). Si tu fais une base de données pour gérer de ventes de pizza tu ne pourras pas faire fonctionner un logiciel de calcul financier avec.

---

Bien sur, la sémantique des données (data model) ainsi que les traitements associés (process model) sont dépendants du problème.

Mais l'architecture de JEE - ou de tout autre plateforme applicative - propose un modèle fonctionnel ainsi que des composants "techniques", tout cela étant indépendant des spécificités du problème. On regroupe tout ca sous l'appellation "framework", même si à mon sens ce terme à un coté trop orienté technique (plomberie).

Un site de e-commerce reste un site de e-commerce, qu'on y vende des chaussures ou des PC. :P

Ok je vois où tu veux en venir...

Citation:

---

Envoyé par pseudocode

Un site de e-commerce reste un site de e-commerce, qu'on y vende des chaussures ou des PC. :P

---

A vendre, chaussures Kingston air sport, très peu servies, norme DDR3/1666, garanties à vie :aie:

A Vendre Cours pour monter une gaming machine qui affiche du 30 FPS sous WOW en résolution 5760x1092 en 3D (avec les lunettes)...
Prévoir 1 € pour le cours et 4500€ pour les pièces...

Citation:

---

Envoyé par tchize_

A vendre, chaussures Kingston air sport, très peu servies, norme DDR3/1666, garanties à vie :aie:

---

avec des socket taille 42 ?

Citation:

---

Envoyé par pseudocode

avec des socket taille 42 ?

---

ne support que les machnes à deux sockets, unijambistes mono processeur s'abstenir :aie:

Salut,

En rentrant du boulot, je suis passé par Montgallet et j'ai vu CA !

http://nsa26.casimages.com/img/2011/...4151224628.jpg

Bi xéon 2x6 coeurs, cartemère et cartes graphiques EVGA watercooled.
4 GTX580 en quad SLI.... Je vous passe le reste des détails, 13000 le bout...

Je pense sincèrement que ce genre de machine devrait être remboursés par la sécurité sociale pour toute personne ayant plus de 493 points dans ce fofo...

++

Laurent