Discussion :

[Invité]

A lire et à commenter ce billet d'un CEO expliquant pourquoi ils n'ont pas voulu embauché un développeur .Net.

[blbird]

Wouaouw. Impressionnant ce blog.

Moi qui sort de 8 ans de Java, suivi de quelques années de DotNet, entre-coupé de différents langages pour la culture, j'ai appris une chose : il n'y a aucun langage qui fait tout mieux que les autres.

[yan]

Ca me fait penser à cette discution :
http://www.developpez.net/forums/d59...ecoles-niveau/

[cs_ntd]

A lire et à commenter ce billet d'un CEO expliquant pourquoi ils n'ont pas voulu embauché un développeur .Net.

Cet article est un torchon, visiblement écris par une personne remplise de préjugée et d'idée préconcues sur une plateforme qu'elle ne connait pas.

Il n'y a qu'a voir les commentaires a la fin. L'auteur avoue lui-meme qu'environ 85% des gens ne sont pas d'accord avec lui...

Pour les gens qui chercherait a comparer un langage vs .NET, ne surtout pas croire un mot de cet article... N'importe quoi d'autre est préférable...

[Thesalan]

Bonjour bonjour,

Alors je ne viens hélas pas contribuer directement à ce débat vieux de bientôt 9 ans, mais je viens solliciter votre aide et vos expériences.

Je dois pondre un rapport sur la comparaison Java/.Net, or je n'ai jamais utilisé de techno Microsoft... Je commence tout juste a mettre le nez dans Visual Studio!

Je suis donc venu ici dans l'espoir que vous pourriez me donnez des axes/pistes de recherches vers quoi tourner ma comparaison...

Je sais que ma demande est très vaste, mais je ne sais vraiment pas par quoi commencer et vers où aller, et je ne dispose hélas que de très peu de temps!

La plupart des informations que j'ai pu trouver sur la toile datent hélas des débuts de .Net et sont je pense inutilisables...

[koyosama]

Je fais un peu developement C#. J'ai fait un peu de développement Java.


C'est vrai que le débat n'est pas même qu'aujourd'hui.
Je suis que débutant pour l'instant en informatique. Je peux dékà te dire qu'en utisant les deux langages, on voit une grosses différence.

Le java, je le trouve un peux compliquer. C# est vraiement pas mal pour faire du winForm ( application fenêtre ).

Les synthaxes sont plus simple en C# que en Java. Mais je pense que la plus grosses différence se trouve dans l'IDE. Visual Studio vs JAVA. Les clients java comme eclipse et netbeans sont pas mal pour débuter mais sont parfois lourds je trouve.

Par contre en C#, microsoft a fait beaucoup d'effort avec Visual Studio. J'ai l'impression qu'en C#, le langages est proche de l'utilisateur. Quand on ne connais rien en java, pour se débrouiller, il faut lire beaucoup , se docuementer et se renseigner surtout que chercher de la DOC java , c'est le parcours du combattant.

Par contre en C# aavec mdsn librairy , il permet de mieux connaître le framework. Et come je l'ai dit microsoft fait de gros effort dessus, surtout qu'il est toujours à jours avec des exemples. Le framework est tellement simple à utliser des fois que c'est tellement évident qu'on peut se passer de documentation.

Java j'ai beau chercher de la doc, il y a de docuementation de référence. je suis aller sur le site de oracle, c'est vraiment abstrait. Mais je dis pas qu'elle existe pas. J'ai peut-être assez en profondeur, ce qui trouve justement que java il faut bien aller chercher par rapport à c# ou tu trouve tout de suite sur le moteur de recherche.

Sans compter le .net est toujours en évolution, Java stagne un peu. je sais même pas si je dois prendre java d'oracle, open jdk ou encore Spring pour faire du développement. Quand je passe de visual studio , c'est vraiment morbide, c'est vrai ça éduque l'utilisateur a faire attention quand il code. Mais bon, voila c'est moins intuitif et prenant que Visual Studio.

Les deux langages permet de faire du web, et des services. Java 7 est sorti, mais bon j'attend toujours le client Français.

Quand je parle de synthaxe, je prend un exmple avec la création d'objet. Il ya un truc en C# que j'adore c'est auto-implementation de propriété, j'ai essayer de voir si en Java il y a avait, yen a pas.

Entre ecrire ça :

Code :

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

1
2
3
4

public class Personne {
public string nom { get;set; }
}

et

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Personne {
private String nom

public Personne() {
}

public String getNom() {
return this.nom;
}


public void setNom(String nom) {
this.nom = nom;
}
}

Mais ce sont que des avis de débutants. Le mieux c'est que tu te fasses deux applications identiques mais avec les deux langages.

[benjaminjc]

Sachant que j'utilise Hibernate pour la persistance en Java, je sais qu'il existe une version pour .NET mais beaucoup moins complète( les briques EntityManager et Annotations sont inexistantes).
J'aimerais savoir si au niveau de .NET la technologie possède des frameworks aussi poussés pour la persistance des données que Hibernate avec la Java Persistance API 2? Et pour l'injection de dépendances?

Cordialement

[blbird]

Sachant que j'utilise Hibernate pour la persistance en Java, je sais qu'il existe une version pour .NET mais beaucoup moins complète( les briques EntityManager et Annotations sont inexistantes).
J'aimerais savoir si au niveau de .NET la technologie possède des frameworks aussi poussés pour la persistance des données que Hibernate avec la Java Persistance API 2? Et pour l'injection de dépendances?

Cordialement

Je te conseil Entity Framework combiné à du LinqToSql pour la syntaxe. Efficace, et assez complet justement pour de gros projets.
Sinon il en existe encore pleins d'autres, open-source ou non d'ailleurs.

[Nathanael Marchand]

Sachant que j'utilise Hibernate pour la persistance en Java, je sais qu'il existe une version pour .NET mais beaucoup moins complète( les briques EntityManager et Annotations sont inexistantes).
J'aimerais savoir si au niveau de .NET la technologie possède des frameworks aussi poussés pour la persistance des données que Hibernate avec la Java Persistance API 2? Et pour l'injection de dépendances?

Cordialement

Injection de dépendance il existe un portage de Sprint ou Unity de Microsoft, à découvrir dans mon article!
http://www.developpez.com/index/redi...nael-Marchand/

[benjaminjc]

Injection de dépendance il existe un portage de Sprint ou Unity de Microsoft, à découvrir dans mon article!
http://www.developpez.com/index/redi...nael-Marchand/

L'article est très intéressant. Merci
Je résume pour voir si j'ai bien tout compris:
Donc Unity pour l'injection de dépendance et le ServiceLocator pour récupèrer des objets de la logique métier. Ensuite Entity Framwork avec LinqTo (SQL, XML ou autre) pour la persistance des objets du domain.
Et ASP.NET MVC3 pour la d'application web (présentation).
L'equivalent de Spring couplé à Hibernate en Java?

Je te conseil Entity Framework combiné à du LinqToSql pour la syntaxe. Efficace, et assez complet justement pour de gros projets.
Sinon il en existe encore pleins d'autres, open-source ou non d'ailleurs.

Merci pour ces précisions. Nathanael Marchand en parle justement dans son article.

[Nathanael Marchand]

L'article est très intéressant. Merci
Je résume pour voir si j'ai bien tout compris:
Donc Unity pour l'injection de dépendance et le ServiceLocator pour récupèrer des objets de la logique métier. Ensuite Entity Framwork avec LinqTo (SQL, XML ou autre) pour la persistance des objets du domain.
Et ASP.NET MVC3 pour la d'application web (présentation).
L'equivalent de Spring couplé à Hibernate en Java?
Merci pour ces précisions. Nathanael Marchand en parle justement dans son article.

Ouép! Ou sinon tu peux utiliser les portages Spring.Net et NHibernate bien qu'ils soient un peu moins dans la "philosophie .Net"

[B.AF]

Sachant que j'utilise Hibernate pour la persistance en Java, je sais qu'il existe une version pour .NET mais beaucoup moins complète( les briques EntityManager et Annotations sont inexistantes).
J'aimerais savoir si au niveau de .NET la technologie possède des frameworks aussi poussés pour la persistance des données que Hibernate avec la Java Persistance API 2? Et pour l'injection de dépendances?

Cordialement

En fait tu confonds l'EJB et JPA avec la persistence. Il existe effectivement des briques logicielles équivalentes; soit fournies par le fournisseur de techno soit par une communauté qu'elle soit libre ou commerciale.

Effectivement, il n'existe pas de conteneur au sens EJB qui garantisse que quelque soit l'implémentation de JPA que tu utilises l'entity manager sera injecté correctement dans tes EJB et que tu puisses controler la persistance de tes POCOs / POJOs par l'utilisation d'annotations.

La plupart des frameworks de persistence existant en .Net sont très bons et matures, en revanche, tu n'auras pas le couplage du conteneur; c'est à toi en utilisant WCF, eventuellement un conteneur IOC et ton outil de persistance de créer ton conteneur d'application et de gérer ton "entity manager".(Et donc sont état, son cache, l'état des entités).

Et ce n'est pas rien car faire une application distribuée en .Net pose en utilisant la persistance de vraies questions :
- La création de DTO
- La liaison entre l'ESB et l'unité de persistence
- La sérialisation (en .Net très peu performante d'une façon générale et incompatible avec beaucoup de scénarios de persistences)

Et les frameworks Ioc n'apportent pas bcp de solutions, si ce n'est de pouvoir créer le service avec une instance de la session de ton framework de persistence, mais l'abstraction reste faible et il faut maitriser son ORM correctement.

Disons que ces architectures en .Net n'ont pas la maturité de leur équivalent en Java.

[benjaminjc]

En fait tu confonds l'EJB et JPA avec la persistence. Il existe effectivement des briques logicielles équivalentes; soit fournies par le fournisseur de techno soit par une communauté qu'elle soit libre ou commerciale.

Effectivement, il n'existe pas de conteneur au sens EJB qui garantisse que quelque soit l'implémentation de JPA que tu utilises l'entity manager sera injecté correctement dans tes EJB et que tu puisses controler la persistance de tes POCOs / POJOs par l'utilisation d'annotations.

La plupart des frameworks de persistence existant en .Net sont très bons et matures, en revanche, tu n'auras pas le couplage du conteneur; c'est à toi en utilisant WCF, eventuellement un conteneur IOC et ton outil de persistance de créer ton conteneur d'application et de gérer ton "entity manager".(Et donc sont état, son cache, l'état des entités).

Et ce n'est pas rien car faire une application distribuée en .Net pose en utilisant la persistance de vraies questions :
- La création de DTO
- La liaison entre l'ESB et l'unité de persistence
- La sérialisation (en .Net très peu performante d'une façon générale et incompatible avec beaucoup de scénarios de persistences)

Et les frameworks Ioc n'apportent pas bcp de solutions, si ce n'est de pouvoir créer le service avec une instance de la session de ton framework de persistence, mais l'abstraction reste faible et il faut maitriser son ORM correctement.

Disons que ces architectures en .Net n'ont pas la maturité de leur équivalent en Java.

Hum, la persistance et les EJBs sont deux choses bien distinctes, je parle même de Spring qui n'utilise pas d'EJB et qui ne s'occupe pas de la persitance. Je ne pense pas me tromper en parlant d'Hibernate et de JPA pour la persistance. Mes propos sont peut être approximatifs cependant et il est vrai que je n'ai pas assez d'expèrience sur ce sujet.

Dans tous les cas, merci beaucoup pour ces précieuses précisions qui m'éclairent grandement sur les capacités de .NET pour ce genre d'application. Et en effet, la maturité des EJBs dans leur version 3 est un grand avantage pour Java sachant que c'est en plus un standard.

[B.AF]

Oui et non. JPA a l'avantage (et l'inconvénient d'ailleurs) d'être une "normalisation".
En gros; hibernate a une implé JPA, comme toplink et d'autres.

Ce qui fait que dans le contexte EJB; l'entity manager peut devenir relativement transparent; même si rien n'empêche une implé particuliére.

En revanche, ce que fait Spring et maintenant en standard dans EJB 3.0 c'est d'avoir des contextes transparents. Il faut voir que l'approche Spring remonte à EJB 1 et 2 qui étaient bcp plus lourds et complexes à mettre en oeuvre. Et qu'EJB 3.0 s'inspire bcp de l'IOC. (IMHO)

Effectivement, j'aurai mieux fait de te dire : attention à bien dissocier les couches.

Là où tu peux te tromper sans grand risque dans Java, ce n'est pas valable en .Net.

Si tu prends Nhibernate en .Net vs le java; tu auras le linq, un support des génériques, des types anonymes, les entity name, le query over, le fluent binding....Mais tu n'auras pas les annotations et JPA comme j'ai lu plus bas, ce qui est un faux avantage puisque ça concerne plutôt l'EJB.

Cependant en termes de fonctionnalités pures, NHibernate et aujourd'hui plus pointu qu'Hibernate; grace à Linq et surtout au langage qui permet de gommer les défauts du HQL (le premier étant que c'est du string).

Si tu viens de Java, tu devras gérer seul ce que JPA et EJB font pour toi via l'entity manager. Il faut mieux connaitre l'outil. Idem; si tu veux créer un entity manager et l'injecter dans WCF pur résoudre des services instanciés avec un entity manager contextualisé (aka EJB) tu devras le faire toi même.

[Nathanael Marchand]

Voici le début d'une série d'articles interessants:
http://blog.kalistick.com/fr/java/wh...-similarities/
http://blog.kalistick.com/fr/java/wh...and-new-world/

[B.AF]

Bof, c'est un peu simpliste. Et bon ça mélange le langage et le tooling; ça ne dit pas non plus qu'en .Net les génériques sont sympas soit, mais la réflexion est une tueuse de perf donc lire ça -

Les avantages de l’implémentation des génériques en C# sont une amélioration des performances (casts inutiles, pas de boxing/unboxing pour types valeurs), et plus de possibilités en termes de réflexion.

- ca fait sourire; notamment pour qui a déjà essayé de comprendre comment les instances de génériques sont créés...

Les propriétés soit, mais dans la vraie vie, les autos on ne s'en sert que pour les démos, et surtout pour le INotify, bien moins pratique que le bean binding...

On compare un langage qui a une release de 2006 avec un langage qui a une release de 2010...Ok je veux bien, mais on voit aussi où vont les nouveaux langages.

Le passage sur Linq c'est à la limite du pas crédible; notamment l'évaluation future et les performances...Et quand on voit l'usage dans la pratique, c'est souvent du grand n'importe quoi.

Les events en C# sont aussi de grands consommateurs de perfs, et c'est poruquoi on trouve encore du pattern observateur. (même si les délégués facilitent la vie)

Ok C# v2010 a bcp de choses en plus; maintenant toutes ne sont pas strictement des mieux au quotidien.
Comme je le pense, Linq devient pour bcp de dev une finalité en soi (on se fout de ce qu'on modélise, on fera du linq); les epxressions lambda et les génériques à trop forte dose ça réduit la fiabilité de l'application et non ça n'améliore la lisibilité d'avoir des chaines de lambdas.

Pareil pour les extensions; c'est sympa, sauf quand on étend une méthode qui finalement n'est pas si générale et provoque des petites failles...

Et je ne pense pas que c'est en disant aux gens 'respectez parce qu'on va vous prouver que c'est mieux' améliore le débat.

Il y a aussi la fermeture de beaucoup d'API; les énumérations sont pas terribles en c#, beaucoup d'API ne sont pas compatibles immédiatement (typiquement EF et WCF)...

[davcha]

Comme je le pense, Linq devient pour bcp de dev une finalité en soi (on se fout de ce qu'on modélise, on fera du linq); les epxressions lambda et les génériques à trop forte dose ça réduit la fiabilité de l'application et non ça n'améliore la lisibilité d'avoir des chaines de lambdas.

Pareil pour les extensions; c'est sympa, sauf quand on étend une méthode qui finalement n'est pas si générale et provoque des petites failles...

C'est pas des arguments contre .NET ou C#, ça, ce sont des arguments contre les développeurs qui font n'importe quoi.

[Nathanael Marchand]

A fool with a tool is still a fool!

[B.AF]

C'est pas des arguments contre .NET ou C#, ça, ce sont des arguments contre les développeurs qui font n'importe quoi.

Oui et non, je veux dire que ça ne rend pas le langage meilleur. Et Linq c'est du .net, pas du C#, donc il y un petit mélange.

J'aime les deux, je reconnais qu'aujourd'hui C# est plus avancé et plus riche que Java.

En java aussi il y a moyen de faire ça :

Code :

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

1
2
3
4
PAQuery query = new JPAQuery(em);
QPerson person = QPerson.person;
List<Person> people = query.from(person).where(person.eyeColor.eq("brown")).list(person);

Ok c'est pas tout à fait du linq mais quand même....

Sans compter qu'avec la complexité du C#; le mélange généricité / lambda et dynamique; on ne compte plus les horreurs où le code inutile.

Si on va par là; c'est à dire mélanger le tooling, les ide, les conteneurs et les frameworks...

Moi je ne comprends pas pourquoi :

Code :

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

1
2
3
4
5
6
public int prop
{
get{return _prop;}
set {_prop=value;}
}

est mieux que

Code :

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

1
2
3
4
5
6
7
8
9
10
public int getProp
{
return _prop;
}

public int setProp(int i)
{
return _prop;
}

Si quelqu'un veut m'expliquer, je suis open, mais je comprends toujours pas....
Et là où je trouve ça encore mieux, c'est qu'aujourd'hui la "mode" semble être les interfaces fluides...Qui rendent bien souvent inutiles la propriété en C#...
Mais bon...

[hegros]

Moi je ne comprends pas pourquoi :

Code :

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

1
2
3
4
5
6
public int prop
{
get{return _prop;}
set {_prop=value;}
}

est mieux que

Code :

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

1
2
3
4
5
6
7
8
9
10
public int getProp
{
return _prop;
}

public int setProp(int i)
{
return _prop;
}

Cela fait la même chose en moins de ligne de code donc c'est mieux..

En C# on peut encore faire en moins de code de ce que tu as écris

Code :

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

1
2
3
4
5
public int prop
{
get;
set ;
}