La même chose est faite par le debugger, d'ailleurs: Les propriétés sont évaluées, les getters non.
Version imprimable
La même chose est faite par le debugger, d'ailleurs: Les propriétés sont évaluées, les getters non.
J'avais mal compris ta première intervention Bluedeep. D'où le sarcasme qui suivit :p
La sérialisation peut aussi passer par les champs...Je ne vois pas trop l'inconvénient...
Pas en .NETCitation:
Envoyé par B.AF
Ne sera pas sérialiséCode:
2
3
4
5
6
7public class MyClass { private int _myField; public int getMyField(){return _myField;} public void setMyField(int value){_myField=value;} }
Le seraCode:
2
3
4public class MyClass { public int MyField {get;set;} }
La sérialisation XML passe uniquement par les champs publics modifiables en .Net.
Avec la vraie sérialisation, tu peux faire ce que tu veux (mais il faut implémenter l'interface ISerializable et le constructeur de désérialisation).
Salut à tous.
D'abord j'ai beaucoup hésité s'il me fallait poser ma question dans le cours de ce thread, ou bien s'il me fallait ouvrir un nouveau thread. Bon j'ai pris une décision, je reste ici.
Voici ma question. J'ai déjà beaucoup entendu dire que un des véritables problème de Java est l'absence d'un véritable RAD à l'instar de visual studio de l'environnement .Net
Quelqu'un peut il me dire (ou bien me donner un lien vers une étude comparée) ce qui se fait simplement, rapidement dans l'environnement VS et qu'aucun n'environnement en Java ne fait avec le même niveau de productivité?
Merci
Bonne question, il y a foultitude d'outils sous Java, et c'est à la fois un avantage et un inconvénient, avantage parce qu'on peut choisir plus efficacement en fonction des besoins, mais inconvénient parce qu'il faut chercher le meilleur outil et que d'année en année ça peut bouger.Citation:
Envoyé par kisitomomotene
Pour la question du RAD purement graphique, il y en a eu un certain nombre , mais ça n'a jamais trop marché, et je n'y crois pas trop, ça génère du code inbouf... et les contraintes techniques liés à ces outils nous obligent à tripatouiller le code généré.
De ce cote celui que j'ai connu je crois que c'était visualage pour générer du swing (c'est loin j'ai un peu oublié)
Pour la question de la productivité en revanche, il y a beaucoup de technologie pour simplifier la création des pages, à coup de template. (du coup c'est plus orienté web,) Les dernières technologies Web que j'ai vu pour se simplifier la vie:
jQuery
GWT
le framework Play2 (tout nouveau)
JSF et ses implémentations (mais je me demande si c'est très utilisé)
note que pour ce que j'ai cité c'est une technologie ou l'autre, il ne vaut mieux pas toutes les mélanger :)
Effectivement, je pense que Visual Studio est globalement plus efficace que les outils java existants pour du RAD au sens drag & drop de composants dans un designer pour créer un écran très simple en 2 temps 3 mouvements.
En revanche puisqu'on parle de productivité, le même Visual Studio est quand même bien à la ramasse pour tout ce qui est assistance à l'écriture de code, refactoring et navigation dans le code comparé à un IntelliJ ou même un Eclipse. Il faut se payer des add-on comme Resharper si on veut atteindre à peu près le même niveau d'expérience de dev.
Je viens de voir cela, mais je veux pas verser dans le cours. Sérialiser, c'est écrire un état d'objet dans un stream, quel que soit le format, quel que soit l'information. En quoi je ne peux pas sérialiser un champs si je le fais explicitement ??????Citation:
Envoyé par Nathanael Marchand
Et autre point, je ne vois pas vraiment l'utilité d'écrire des méthodes pour le get / set en C#; mais bon je suis ouvert à tout...
D'où plusieurs implémentation en .Net dont une qui me semble sérialiser les fields ????
Code:
2
3
4
5
6
7
8
9[DataContract] class MyObject { public MyObject(Guid id) { this.id = id; } [DataMember(Name="Id")] private Guid id; public Guid Id { get {return id;}} }
Ce n'est pas ce que Nathanael Marchand voulait dire:Son post expliquait que dans le cas de la sérialisation XML comme celle utilisée pour les web services, seuls les membres publics (champs ou propriétés) modifiables seront sérialisés.
Dans ce que j'appelle la "vraie" sérialisation de .Net, les choses sont différentes: On a droit à un vrai "constructeur de désérialisation", permettant de sérialiser et désérialiser les membres readonly.
Pour la sérialisation WCF, je ne sais absolument pas si l'attribut DataMember permet de sérialiser les membres privés: Je n'ai jamais essayé, toutes mes classes WCF n'ont que des membres publics.
La sérialisation fonctionne sur les champs privés et même aussi sur des propriétés privées (même si la propriété a un public get et un private set). :ccool:Citation:
Envoyé par Médinoc
C'est quoi un vrai sérialisation ? Ce n'est pas parce que Microsoft propose une implémentation sous format XML qu'il faut généraliser cela au langage et en faire une discussion dans un comparatif Java et C#. Ce ne sont pas des éléments du langage, mais plutôt du Framework (et là encore en java, il y a ce qu'il faut en sérialisation, y compris côté proto buff)Citation:
Envoyé par Médinoc
Ce que j'appelle la "vraie" sérialisation de .Net, c'est le système utilisant:
- L'attribut Serializable
- Optionnellement, l'interface ISerializable et les types qui vont avec (SerializationInfo, StreamingContext et le constructeur de désérialisation) pour les types qui ne sont pas triviaux à sérialiser.
Là il ne s'agit pas de "sérialisation XML" mâchée avec attributs, mais d'un système permettant de sérialiser ce que tu veux et surtout de construire en désérialisant (par opposition à construire puis désérialiser, ce que font la sérialisation XML et COM). Indispensable pour les types comprenant des variables readonly.
PS: Si l'on se limitait aux éléments du langage, C# l'aurait depuis longtemps emporté sur Java. C'est la plate-forme entière qu'il faut considérer.
Pour rappel, il s'agit bien d'un comparatif des technologies : plateforme / framework / langage :)Citation:
Envoyé par B.AF
D'ailleurs, il devient difficile de séparer langage et framework dans des "langages" aussi évolué. Par exemple sous Java, le package java.lang fait complétement partie du langage !
rien de pire qu'un langage avec des "packages"
Magnifique troll, aucune justification. :roll:Citation:
Envoyé par sybil
je ne vois rien de dérangeant qu'un langage utilise des packages au contraire je trouve ça super ça permet aux développeurs de se retrouver c'est comme si tu rentrais dans une bibliothèque où les livres ne sont pas rangés par spécialité, tome et autres. ce serait un foutoir pour trouver un livre dis toi que les packages aussi sert à çaCitation:
Envoyé par sybil
En plus, .Net a les deux: Namespaces et Assemblys.
tu avais fait un petite faute de frape que j'ai corriger pour toi :pCitation:
Envoyé par sybil
Choisir .net (WCF, WF, etc.) c'est aussi choisir Microsoft et tout son écosystèmes : SQL Server, BizTalk (HIS, ESSO, etc.), TFS, xCRM, MSDTC, SharePoint, etc.
Pour que Microsoft soit intéressant pour tout le monde, il faut aussi que des boites externes puissent créer et vendre des composants. C'est donc normal que tout ne soit pas out of box.
Ensuite choisir MS, c'est avoir la possibilité d'avoir des extensions de support de produits de plus de 10 ans. Généralement dans l'open source, les projets sont abandonnés ou des changements majeurs sont effectués ce qui casse la compatibilité des versions.
Bref quand je dois parler à des environnements centraux et migrer 12000 postes d'une version n d'un logiciel à sa version n+2 (voir 3 ou 4), j'ai le support de Microsoft pour analyser tous les impacts.
Avant aussi j'étais pour le tout gratuit, force est de constater que dépasser un certain volume, un certain délai, le gratuit coûte cher.