MVC et WInforms

[mathias kluba]

Hello!

Je bosse en ce moment sur un petit projet perso, que pour diverses raisons je fais en Winforms.

J'ai fini par faire un mini-framework MVC et je voulais un avis externe (car je n'arrive pas à faire de pair-programming avec ma double personnalité maléfique... elle n'est jamais d'accord avec moi!!)

J'avais déjà bossé sur un truc pareil, avec comme inspiration à l'époque CAB.

Aujourd'hui je m'inspire plus de mon expérience Web, et des frameworks MVVM.

Mais j'ai une maladie mentale incurable qui s'appelle "PFSQOPFC" (pourquoi faire simple quand on peut faire compliqué).

D'où la nécessité d'un avis :)

Comme un schéma vaut mieux qu'un long discour, voici en gros l'archi:

J'ai mis le Broker en noire pour dire que c'est lui qui dispatch les Commands/Events.
Les "Event" émis par l'UI devrait changer de terminologie pour éviter la confusion, je devrais plutôt parler d'Action comme dans les frameworks MVVM.
Bien sûr, la partie Command/Model/Event ne fait pas partie du MVC, c'est inspiré du CQRS, mais vous avez l'idée.

J'ai codé ça dans un style "très orienté objet", cad que pour s'abonner à un événement il faut implémenter une interface:
ISubscribeToEvent<EventType>

Le problème c'est que le Contrôleur en a une tonne...
J'hésite à le refaire en mode "attribut":
[Subscribe]
public void OnEvent(EventType myEvent){ ... }

Laquelle des 2 vous préférez en général?

Finalement, je me rend compte que pour une petite fonctionnalité, j'écris beaucoup de code "non métier" ce qui est dommage.
Ex: je veux pouvoir éditer un objet dans l'interface? Il me faut faire:

• un Event "EditObjectAction" et l'envoyer de l'UI
• souscrire dans le controller "ISubscribeToAction<EditObjectAction>".
  C'est le bon moment de faire de la validation etc. mais la plupart du temps il n'y en a pas... faut voir si je peux pas générer des méthodes abstraites lors de la phase IOC pour générer un comportement par défaut.
  Ensuite, ce controller doit envoyer une commande "EditObjectCommand"
• ma couche business va s'inscrire à la Commande "ISubscribeToCommand<EditObjectCommand>" et faire la maj
  pour ensuite envoyer l'Event "ObjectEditedEvent"
• le controller s'abonne à ça "ISubscribeToEvent<ObjectEditedEvent>". L'avantage ici c'est que plusieurs controllers (et donc plusieurs UserControl) peuvent appliquer l'impact d'un changement
  A ce moment, le controller va transformer le "Model" en "ViewModel" pour le donner à ma vue via une interface IView:
  this.myView.RefreshViewModel(AutoMapper.Map<Model, ViewModel>(model))
  Ou parfois avec juste des manipulations atomiques, comme:
  this.myView.AddSubItem(newSubItem)
• Et coté vue, il faut donc que j'implémente l'interface IMyView qui permet la manipulation de l'UI depuis le controller

Bref, ça fait beaucoup de chose, peut-être pour rien ;)

J'ai plusieurs pistes de refactoring, mais c'est la que j'en appel à votre avis.

Déjà il y a la manière de s'abonner par attribut, peut-être moins verbeuse.

Je pourrais passer par un vrai ViewModel au sens MVVM, cad un modèle que le controller manipule, et qui impact immédiatement l'UI à l'aide de DataBinding.
Mais je ne suis pas fan de DataBinding, et je veux que l'UI envoi des messages "Action", au lieu que le controller s'abonne aux changement du ViewModel...

Il y a aussi l'histoire de génération de code au Runtime: je pourrais faire des interfaces/classes abstraites, et lors de l'IOC je construit un comportement par défaut... si on souhaite le surcharger il suffit d'implémenter l'interface/méthode abstraite.

Il y a sans doute des idées possible avec de la "Convention Over Configuration" aussi, mais je ne vois pas trop où pour le moment.

Pour ceux qui font du MVVM, vous trouvez pas que c'est un peu lourd par moment, et qu'il faut implémenter beaucoup de code pour juste faire une maj en base d'un champs sur le bouton save ? :)

Comment faites-vous?

[Simon Mourier]

On crée une interface quand on a à implémenter un contrat, donc il faut que l'interface ait des méthodes, des propriétés, des évènements. On utilise un attribut pour définir un comportement statique/défini. Une interface qui ne sert que de marqueur (vide) devrait plutôt se présenter comme un attribut (il y a des exemples dans le framework comme INamingContainer, mais c'est plutôt rare). Un attribut compliqué qui sous entend un comportement devrait être une interface.

Sur le coté "trop lourd" pour des choses simples, ça dépend un peu de ta cible. Si tu veux faire des "petits" développements, c'est certainement "overkill", mais si tu es en train de designer un framework qui sera utilisé par des dizaines de développers de tout poil pour développer une appli de 1000 écrans, et que tu veux que tout soit bien fait de la même manière, là, ça vaut le coup d'y passer du temps (et surtout d'être capable de faire vivre ce framework dans le temps pour coller aux besoins des développeurs).

My 0.02€

2012/8/19 mathias kluba <mathia...@gmail.com>

[Rui Carvalho]

Je t'avouerai que je me pose les mêmes questions à chaque fois que je dois faire un outil windows - hors du contexte web qui est le mien habituellement donc. 

Je n'ai jamais trouvé de solution satisfaisante avec ce qui existe actuellement, le coût de gestion de la "tuyauterie" étant en général trop fort à mon goût...Une autre chose qui me chiffonne aussi est qu'il n'y a pas un framework générique qui permette de définir une logique d'interaction utilisateur que je puisse réutiliser en mode console/desktop/web. Les problématiques ne sont pas les mêmes me direz-vous, oui mais il y a bien des choses que l'on pourrait mettre en commun tout de meme, non? La seule différence pour moi résidant finalement dans la gestion des events entre ce qui desktop et web, et là encore on pourrait imaginer une solution générique avec une sorte de binding d'évents.

En dehors du bienfondé, d'apporter un certain nombre d'amélioration dans le modèle de développement d'une appli desktop (comme ce que peuvent apporter des modèles mvc, mvvm ou outre), il faudrait je pense se concentrer sur ce que cela apporte au développeur afin qu'il puisse se focaliser au max sur son code métier et écrire le moins possible de code de liaison et de code de couches intermédiaire.

Peut être que tu pourrais partir d'une application winforms standard simple mais représentative et qui fonctionne, puis faire des séries de refactoring pour en extraire les parties techniques de liaisons qui pourraient former un framework?

Rui.

2012/8/19 Simon Mourier <simon....@gmail.com>

[Frédéric Fadel]

Vue la question de Mathias et les remarques de Rui : "...je me pose les mêmes questions à chaque fois...", "...le coût de gestion de la 'tuyauterie' étant en général trop fort à mon goût...", "...écrire le moins possible de code de liaison et de code de couches intermédiaire...", "...Je n'ai jamais trouvé de solution satisfaisante…", désolé Rui je te cite dans le désordre ;-)

J’ai à mon tour, à défaut de réponses, quelques questions pour tous ! 

Et si l’hypothétique solution satisfaisante de Rui devrait exister, grâce à vous ! Que mettriez-vous dedans ? 

Comment établirez-vous la liaison entre le code métier et le code technique ? 

Distingueriez-vous déjà ces deux types de codes ? 

Cette solution, serait-elle conceptuellement identique pour une appli Web, une appli Winform, une appli- Cloud ? 

Êtes-vous fait pour utiliser, votre propre solution ? Ou sa mise au point va vous occuper à plein temps, sans jamais avoir le loisir de l’utiliser ?

happy fin août, et à+,

Fredy

2012/8/20 Rui Carvalho <r...@rui.fr>

[Mathias Kluba]

Hello,

Merci pour vos feedback ;)

Alors, au départ j'ai fait une appli "a la vite fait" mais qui répond au besoin.

Je suis pragmatique, j'invente pas un framework pour le plaisir (enfin si ça m'arrive, mais pas si j'ai des contraintes de temps).

Si j'en suis arrivé à mon framework, c'est parce que ça devenait difficile à maintenir/faire évoluer.

Quand la logique métier est dans

l'interface, on se retrouve à copier/coller du code entre les Form/UserControl, et c'est mal.

J'ai fait donc la distinction de code métier/UI, mais il y une a une autre: la logique "applicative"

Cette logique est propre à l'application et à un contexte, pas à un métier, donc c'est couplé avec l'interface.

C'est pourquoi je distingue:

- UI

- Controller: logique applicative, avec de la validation etc.

- Services: logique métier

(- Dal: mais je ne vais pas m'étendre dessus)

le choix de découpler les couches à l'aide d'une communication par message, c'est une façon de faire mais il y en à d'autre (mais a pas mal d'avantages)

Mais j'en suis arrivé à un point ou la plomberie me fait perdre du temps pour faire une fonctionnalité.

D'une part parce que la méthode "par message" nécessite une classe pour chaque UIAction/Command/Event.

En fait, c'est surtout lié à la partie CQRS like, ce qui n'a rien à voir avec l'UI et MVC.

D'ailleurs, j'ai fait une UI avec beaucoup de "wizard" pour chaque commandes métiers, au lieu de laisser l'utilisateur éditer la grille comme dans excel...

En fait, en re-organisant le code/namespaces, avec plus de plomberie automatique du coté IOC (avec des conventions) j'en suis arrivé à un truc pas mal, plus facile à faire évoluer, avec moins de code.

J'ai bien extrait la partie MVC que je peux open-sourcer, mais finalement c'est très peu de choses.

J'ai vu que Caliburn.Micro n'a qu'une version du code, avec des CSPROJ qui références les mêmes sources, et avec des #if pour compiler pour Silverlight ou WPF ou WindowsPhone ou WinRT.

Alors pourquoi ne pas l'adapter à winforms? car winforms c'est le passé;) mais j'ai hésité avec le faire pour ne pas re-inventer la roue.

Ceci dit, malgré un découpage "trop précis", c'est plus facile à identifier les bugs, et faire des tests vraiment unitaires, donc c'est une bonne chose.

Pour finir, tu as raison Rui comme quoi le web et les appli desktop partage quelque chose de commun.

En fait, quand j'ai commencé mon framework, je me suis inspiré de asp.mvc:

- c'est mon controller qui décide quel userControl afficher

- mon controller renvoie des "viewModel" à l'UI, comme les pages web qui utilisent Ajax pour récupérer des json afin d'updater la vue sans reconstruire la page

- la spécificité des applis desktop c'est que le controller peur pousser des données à la vue. Mais c'est maintenant le cas dans me web, avec les websocket ou longpolling, et ça se fait de plus en

plus facilement (voir l'integration de SignalR dans ASP.Net 4.5)

- la vrai différence avec le web, c'est que l'UI et le Controller dialoguent via HTTP, donc pas le choix, c'est par messages. J'ai forcé ce comportement dans mon framework, mais ça alourdie le code.

Mais le gros avantage est le faible couplage:

la vue "master" ne connait pas la vue "details", elle envoie juste un message "TrucSelected" et le controller "DetailsController" qui traite ce message (via une espèce de routing) va updater sa vue.

plusieur controller/vue peuvent donc potentiellement s'abonner à ce message.

Bon, j'arrête la, mon email est déjà trop long, mais je suis fan de rapprocher le web et le desktop (mais pas faire du web comme du desktop, comme avec asp.net, ou vis vers ça, il faut un entre 2)

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

[Tomasz JASKULA]

Pourquoi se compliquer la vie. Un bon vieux pattern MVP marche parfaitement bien avec les Winforms. Il n'y a pas besoin de framework particulier.Suivant le but que vous voulez atteindre (unit testable par exemple), il y a des variantes avec la vue passive, contrôleur superviseur ou un model de présentation. C'est simple est efficace. Pas besoin d'apprendre un framework ou d'en subir les limites.

A+

Thomas

2012/8/20 Rui Carvalho <r...@rui.fr>

[Mathias Kluba]

Merci pour ces liens!!!

En effet, rien n'empêche d'avoir les mêmes concepts en winforms, c'est juste que tous les controls ne sont pas databindable..

Je ne suis pas fan du databinding (à tord peut-être) et j'ai contourné cela en

manipulant l'UI via une Interface (IMyView).

C'est sûr, ça fait plus de code, me Databinding fait ça "magiquement".

Au final j'ai un truc qui ressemble à mvp, sauf que la vue ne connait pas le presenter, la communication étant pas messages (Action)

PS: on pourrait finalement porter Caliburn à Winforms, qui sera limité aux controls supportant le bindings.

On peut aussi le porter au Web, avec Knockout.js qui est génial

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

Le lundi 20 août 2012 à 11:35, Florent Dugué a écrit :

Bonjour à tous

Pour ton avant dernière question Mathias, je suis d'accord, c'est un peu lourd par moment, mais le but du MVVM (de mon point de vue), ce n'est pas de faire court et de coder un update dans une SaveButton_OnClicked, mais de faire mieux (testabilité, SRP, ...). En plus, tu profites (enfin, pas toi dans ce cas) du binding WPF, qui est quand meme pas mal une fois qu'on a apprit les différentes possibilités. Rien à voir avec le DataBinding "à l'ancienne" de WinForm.

Je rajoute un extrait d'une page de StackOverflow (http://stackoverflow.com/questions/982978/mvvm-for-winforms) :

MVVM was specifically created for WPF, in order to take advantage of WPF features like bindings and commands. Windows Forms doesn't have these features(*), so it doesn't really make sense to try to apply the MVVM pattern to a Windows Forms application... You should probably use MVC or MVP instead.

(*) It actually has some basic support for data binding, but not as powerful as in WPF...

Après, "y en a qu'ont essayé", donc pourquoi pas :

http://www.codeproject.com/Articles/364485/MVVM-Model-View-ViewModel-Patte

http://blog.soat.fr/2012/02/comment-utiliser-mvvm-avec-windows-forms

[Mathias Kluba]

Hello,

Tu as tout à fait raison.

Mais j'aime me contraindre avec un

framework ;) pour respecter une même convention et me poser moins de questions (est-ce que j'ai le droit de faire cette dépendances? qui est responsable de quoi?)

mais comme je disais, ce n'est pas ça qui me coûte finalement, c'est surtout la communication

par messages et le CQRS like.

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

[Mathias Kluba]

Merci pour ce lien!

En effet la plomberie fait peur, on a déjà un thread sur ce forum sur le MVVM...

Mais je viens de tester caliburn (oui je suis un noob en WPF/MVVM) et je trouve ça très sympa car il fait plein de truc automatiquement par défaut si tu respecte une convention. 

Ex: si le bouton s'appel "SayHello", son click va appeler la méthode "SayHello" du Viewmodel.

Le button sera même grisé s'il y a une

property "CanSayHello" .

Bref, tout est dans la convention ;)

ça m'a donné envie de tester dans mon miniframework: avec ValueInjector (un equivalent d'automapper) on peut mapper les controls sur un model (textboxFirstname.Text sera mappé à changePeopleCommand.Firstname) et je mapp par réflection les "OnClick" aux méthodes compatible qui porte le "même" nom (buttonSayHello.Click sera mappé à la méthode SayHello)

bref, une fois la glue faite, il n'y a presque plus de code à faire!

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

Le lundi 20 août 2012 à 16:10, Florent Dugué a écrit :

Concernant le point '"Caliburn pour Winforms", y a un semblant de début de pont WinForms - "framework MVVM" ici : http://mvvmfx.codeplex.com/

A voir ...

Sinon, pour la librairie universelle Web/WinForms/WPF/Console, on a Caliburn qui, sur le papier, doit permettre d'avoir une appli WPF / Silverlight facilement. En pratique, je n'ai jamais testé.

Mais surtout, sachant que, à vue de nez, 90% minimum des applis sont mono frontend (je vais l'appeler comme ça), quel choix va etre fait entre une techno multi frontend qui va couter plus chere à mettre en place, par rapport à une autre spécifique à, au choix, WPF, Web ou console ? Déjà qu'actuellement, les gents sont pas chauds-chauds avec le MV-quelque-chose, car ca coute plus cher que du "SaveButton_OnClicked", à mon avis, pas grand monde.

[Jérôme Avoustin]

100% d'accord avec Thomas...

Et j'ai actuellement les mains dans un cambouis pareil.

Ma solution : du MVP en passive view (enfin le plus possible).

Comme c'est du legacy code que je refactore, aujourd'hui c'est encore bancal, mais ça commence à ressembler à quelque chose.

En gros :

• des user control (qui auparavant contenaient absolument tout le code de l'appli et c'est encore le cas en partie)
• des vues représentées par des interfaces
• des sortes de "façades" sur les user control, qui implémentent les vues
• Un hub d'événements (interface) qui sert d'abstraction aux événements UI
• des presenters/contrôleurs (j'ai toujours pas trouvé le nom) qui n'ont aucune méthode publique, et fonctionne en publish/suscribe sur le hub d'événements
• pour les tester j'injecte des spy
• des repositories
• quelques services pour supporter certaines fonctions
• le tout câblé avec de l'IoC

Jérôme

2012/8/20 Tomasz JASKULA <thoma...@hotmail.fr>

[Mathias Kluba]

Ah alors ça ressemble à ce que j'ai ;)

Tu utilises quoi comme hub d'événements?

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

[Jérôme Avoustin]

Une pauvre interface :) (et son implem qui s'abonne aux événements UI pour les propager)

2012/8/21 Mathias Kluba <mathia...@gmail.com>

[Mathias Kluba]

bon, je vois qu'en WPF/Silverlight on utilise pas mal Caliburn

en web, ASP.Net MVC devient de plus en plus standard (ASP.Net 4.5 ressemble de plus en plus à MVC)

mais en winforms, il y a CAB *vomi* et sinon tout le monde refait son framework.

même sur stackoverflow chacun à sa solution maison.

Je viens de découvrir MVC# mais ne me convient pas.

En fait, je deviens sans doute vieux, mais après avoir codé plein de framework, j'aimerai bien eviter de recoder de la plomberie, pour se concentrer sur le métier (même si je suis lié à une implem de framework)

dans le même sujet, quelqu'un utilise NakedObject?

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

[Mathias Kluba]

a une époque on voulait faire une prez multi-speacker, pour montrer les différentes façon de coder une appli:

- génération de code, par designer ou scafolding

- génération dynamique d'ui comme naked object

- les différents pattern mvc/mvp/mvvm/etc

- il y a aussi l'approche de MonoTouch.Dialog

- etc.

qui est-ce qui est motivé pour parler se SA façon de faire (même si c'est un framework perso ou commercial) ?

je pense qu'il y a tellement à dire qu'il faut se limiter aux applis desktop, pour le web c'est encore un autre vaste sujet qui peut faire l'objet d'une autre session

si vous avez déjà une appli de demo à présenter, tant mieux, sinon je propose la classique gestion de TODO, ou le carnet d'adresse (mais si vous trouvez un truc plus cool, proposez! )

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

Le mardi 21 août 2012 à 13:08, Florent Dugué a écrit :

Il existe une évolution du MVVM, le MVP-VM.

En gros, on dégage toute intelligence du ViewModel pour le mettre dans un Presenter.

D'où gain en testabilité, réutilisabilité, etc ...

Un petit article appliqué à WinForms : http://aviadezra.blogspot.fr/2009/08/mvp-mvvm-winforms-data-binding.html

Et un autre à WPF : http://msdn.microsoft.com/en-us/magazine/hh580734.aspx

[Florian Nouri]

L'idée est super bonne en tout cas !

2012/8/21 Mathias Kluba <mathia...@gmail.com>

[Guillaume JAY]

2012/8/21 Mathias Kluba <mathia...@gmail.com>

En fait, je deviens sans doute vieux, mais après avoir codé plein de framework, j'aimerai bien eviter de recoder de la plomberie, pour se concentrer sur le métier (même si je suis lié à une implem de framework)

Je ressens la même chose.

Je viens de découvrir (sur le tard, certes, mais du coup aussi la techno est bien avancée) le Code-First d'Entity Framework et la réduction de plomberie que j'y ai trouvé - enfin, je suis encore en phase d'acquisition, je ne suis pas a l'abri d'une déconvenue -  m'est très plaisante. Notamment, la suppression des DTO, la pollution des objets métiers par les concepts SQL étant  - pour moi - suffisamment faible pour être acceptable (sans compter que je fais tout en attribut, alors qu'en fluent je pourrai réduire de beaucoup cette pollution)..

dans le même sujet, quelqu'un utilise NakedObject?

Non, mais maintenant que je vois que ma difficulté suivante de plomberie, c'est les interfaces utilisateurs de style CRUD, ca m’intéresse...

Guillaume

[Mathias Kluba]

si t'es sur EntityFramework, et que tu fais du web, et que tu veux aller vite pour générer quelque chose qui marche (et avoir rapidement un feedback utilisateur) tu as aussi MVC Scaffolding

ça génère des interfaces crud à partir de ton modèle, et des décoration ([Required] par exemple) 

Après, tu peux partir du code généré pour customiser l'interface.

Naked Object va généré une interface dynamiquement (pas de génération de code) et ça a aussi l'air de bien s'intégrer avec Entity

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

[Mathias Kluba]

C'est marrant, juste au moment où on parle d'utiliser mvvm pour cibler plusieurs "plateformes" pour unifier la façon de faire, voici une vision basé sur .net: 

http://feedproxy.google.com/~r/OD/dotblog/~3/4QUEnA5OdDw/post.aspx

[Florent Dugué]

Très intéressant !

[Guillaume JAY]

En tant qu'"expert" .net - novice java, je trouve forcément sa thése du Multi-plateformes  par .Net/Mono très séduisante, mais est ce que c'est vraiment viable/vendable ?

Prés naïvement : peut-on être confiant dans la pérennité de Mono ?

2012/8/23 Mathias Kluba <mathia...@gmail.com>

[Jérôme Avoustin]

Je me rappelle qu'à une époque "certains" (pas forcément pro MS d'ailleurs) disaient que WPF allait permettre à Microsoft d' "aspirer" les développeurs des autres plateformes et les entreprises.

On reparle de tout ça dans 5 ans ? :)

2012/8/23 Guillaume JAY <guilla...@gmail.com>

[Rui Carvalho]

dans les faits mono existe depuis presque le début de .net, il est toujours là, et malgré tout MS n'a pas fait beaucoup d'efforts dans ce sens (meme si au niveau frameworks ils sont un peu plus ouverts aujourd'hui qu'il y a 10 ans...).

donc le projet est actif et bien suivit, pas de soucis de ce coté. De plus, ce qui est évoqué dans l'article c'est bien monotouch et monodroid, qui, même si ce n'est pas du tout précisé dans l'article, sont des produits commerciaux. Autant on peut pas faire tourner des app WPF sous mono parce que tout le monde s'en fous, autant pour le core framework et pour la partie mobile il n'y a pas de souci...

D'ailleurs soit dit au passage, c'est un très bon article de synthese sur le sujet je trouve (meme  si dans les faits je ne dois être qu'a 50% d'accord avec lui ;-)

Rui.

2012/8/23 Guillaume JAY <guilla...@gmail.com>

[Guillaume JAY]

 

D'ailleurs soit dit au passage, c'est un très bon article de synthese sur le sujet je trouve (meme  si dans les faits je ne dois être qu'a 50% d'accord avec lui ;-)

C'est à dire ?

Guillaume

[Fabrice MICHELLONET]

En parlant de Cross platform, je m'attendais à entendre parler d'initiatives comme Phonegap ou autre...

Est-ce un oubli volontaire?

[Mathias Kluba]

Dans cette article, l'auteur dit qu'il ne croit pas en l'avenir du HTML (5).

Franchement, pour faire une interface "à la metro", pas besoin d'un gros moteur WPF.
D'ailleurs, MS permet de faire la même interface en HTML5+JS dans Windows 8.

Il y a plein d'exemples d'applis Web magnifiques, très réactives...
J'en ai même découverte une qui est 100% WebGL et qui fait alors très native (http://pattern.dk/sun/ ne fonctionne que sur iPhone).
Du coup, on peut même imaginer un moteur "à la silverlight" qui exploite WebGL: le résultat sera le même, mais ça sera supporté directement par le navigateur, sans plugin.
Tout va sur le Web: le client Mail, la galerie Photo, les "google doc" ou "Office 360"...
Alors à une époque on disait "oui mais tout n'est pas fait pour le Web, je vois mal VisualStudio en HTML": alors tester ceci: https://c9.io/

Mais j'ai personnellement un gros frein à l'adoption: c'est le Javascript.
Certes, ça s'est grandement amélioré, coté moteur ou avec des frameworks comme JQuery. On peut même faire du MVVM ou du Reactive Extension!  (http://knockoutjs.com/ et http://msdn.microsoft.com/en-us/devlabs/gg577610#js )
Mais ça reste pour moi un langage de merde, à des années lumières des langages modernes ou des machines virtuelles.

Pourtant faire du .net dans le navigateur ça existe: Google Chrome possède un "moteur" sandboxé qui exécute des applications "natives" (compilé): http://www.chromium.org/nativeclient
Il supporte aussi le bytecode LLVM: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client
Et mono est compatible LLVM!
Il n'y a qu'à voir le résultat: un jeux en Mono+XNATouch: http://chrome.supergiantgames.com/

Ce qui rejoins la question "et mono?"
Et bien Mono est présent sur iPhone et Android, voir même sur PS3, XBOX et Wii!
C'est de plus en plus utilisé pour le jeux: http://unity3d.com/unity/publishing/
Alors allez vite faire des jeux cross-plateforme avec http://syntaxtree.com/blog/2012/02/22/announcing-unityvs/ !!!
(et pour les développeurs qui ne savent pas faire de la 3D ou des textures, vous pouvez en acheter sur le Unity3D Asset Store: http://unity3d.com/unity/asset-store/ )


Donc la conclusion: Java était sur une bonne voie pour le "write once, run everywhere", mais finalement .Net s'en sort mieux aujourd'hui ;)

[mathias kluba]

J'aimerai ajouter:

Mono est mature et complet coté VM/Compilateur etc. (vu qu'ils respectent les specs qui sont ouvertes)

La où ils ont parfois du retard, c'est sur l'implémentation du framework.

Mais comme ces derniers temps Microsoft rend open-source de plus en plus de bout du framework, ces bouts sont automatiquement inclus dans mono :)

J'aimerai bien trouvé une carte du framework .net et de ce qui est opensource ou pas... mais j'ai pas trouvé.

Je liste déjà quelques sources:

- http://razorengine.codeplex.com/

- http://aspnetwebstack.codeplex.com/

- http://entityframework.codeplex.com/

- http://mef.codeplex.com/ 

Faut ésperer que la liste s'allonge :)

(ps: n'hésitez pas à ajouter quelque chose que j'oublie)

[Yann Schwartz]

Au passage, UnityVS, l'add-on Unity pour développer des projets Unity dans Visual Studio est le rejeton de JB Evain.   http://syntaxtree.com/blog/2012/02/22/announcing-unityvs/ 

2012/8/23 Mathias Kluba <mathia...@gmail.com>

[mathias kluba]

Big Up :)

[mathias kluba]

Dans son article, il parle de sa Glue qui s'adapte à toutes les UI: c'est le MVVM avec  https://github.com/slodge/MvvmCross 

Caliburn.Micro fonctionne aussi pour WPF/Silverlight/WP7 et WinRT: il ne lui reste que MonoTouch et MonoForAndroid.

Finalement, avec ces multi-device, on va enfin apprendre à coder des applis avec du code portable, jusqu'au ViewModel en tout cas.

(Trôle? : personne ne veut cibler Linux? un petit portage de Caliburn.Micro pour GTK#, c'est faisable ;) )

[Mathias Kluba]

pendant ce temps: le même debat

http://branch.com/b/a-blow-to-html5#aiawqfjalh8

on oublie que l'avantage du web c'est qu'on trouve facilement une "appli" via google ou une simple URL, qu'il n'y a pas besoin de l'installer, et que les maj sont maitrisées

ce qui change la donne pour les applis natives c'est les "apps store": point d'entré pour facilemen trouver une app, pour centraliser les maj, sandboxing etc.

le debat est sans fin ;)

--
Mathias Kluba
Twitter: @mathiaskluba
Blog: http://grozeille.com

[Guillaume JAY]

2012/8/24 Mathias Kluba <mathia...@gmail.com>

 

qu'il n'y a pas besoin de l'installer, et que les maj sont maitrisées

Le gros avantages des mise a jours est quand même pour moi  un peu contrebalancés par le souci des navigateurs "recevant", qui reste toujours un point d'achoppement, de plus en plus réduit, certes.

Le firewall du boulot m'empêche de bien suivre l'histoire de facebook/IOS, mais je trouve que si "même" Facebook n'arrive pas à un résultat satisfaisant en HTML5, ca n'est pas très rassurant : dans un article, un responsable parle quand même de deux fois plus rapide en natif pour "scrolling through the News Feed", ce qui ne me semble pas a priori la tache la plus lourde qui soit..

Guillaume