Je ne pensais pas que c'était possible, mais je viens de parler à une collègue qui m'a dit qu'elle l'avait déjà fait. Est-ce qu'elle me tire les vers du nez ?
Réponses
Trop de publicités?
Ce n'est pas quelque chose que l'on peut faire automatiquement.
L'astuce est que Winforms et Webforms représentent tous deux un formulaire à l'aide d'une simple classe. Cependant, les instances de la classe dans Webforms sont de courte durée par rapport à Winforms ; chaque instance de la classe Webforms ne représente qu'une seule requête HTTP, plutôt que toute la durée de vie du formulaire, comme c'est le cas avec Winforms. Chaque fois que vous gérez un événement pour votre formulaire en ASP.Net Webforms, vous travaillez avec une toute nouvelle instance de la classe. Microsoft s'est donné beaucoup de mal pour essayer de couvrir ce problème autant que possible, mais en fin de compte, ce n'est tout simplement pas une bonne idée de penser à un Webform dans les mêmes termes qu'à un Winform.
Il est tout à fait possible de réécrire une application Winforms pour l'adapter à Webforms, mais ce ne sera que cela : une réécriture.
Colin Mackay
Points
9303
Oui, c'est possible. Si vous avez suffisamment bien conçu l'application, il devrait être relativement facile de convertir une application Win Forms en une application Web Forms en remplaçant simplement la couche d'interface utilisateur. Vous réutilisez les couches de logique et de données (où se trouvent toutes les fonctionnalités).
Il est évident qu'il faut écrire une nouvelle couche d'interface utilisateur à partir de zéro, mais si la couche logique est suffisamment bien écrite, cela ne représentera pas un travail trop important par rapport à l'écriture de toute l'application à partir de zéro.
Toutefois, même si votre demande est très bien rédigée, il y a des obstacles à surmonter. La couche logique peut supposer une application avec état, auquel cas elle peut s'appuyer sur un chargement paresseux. Dans une application web, vous avez un modèle sans état qui est exécuté sur des requêtes et des réponses. Dans ce scénario, vous savez exactement ce dont vous avez besoin dès le départ et vous pouvez charger uniquement les éléments dont vous avez besoin et pas d'autres choses qui pourraient être nécessaires plus tard... parce que plus tard, il y aura un autre cycle de demande/réponse et toutes les données que vous collectez maintenant seront supprimées dès que la réponse actuelle sera terminée.
J'ai récemment mis la logique d'une application qui était à l'origine un WinForms dans MVC et le plus grand obstacle à l'obtention d'une vitesse réactive est le fait que, bien que raisonnablement bien écrit, la couche logique a supposé un environnement avec état. La même application est également réécrite pour WPF (un autre environnement avec état) sans trop de problèmes.
willvv
Points
3071
La conversion d'une application de bureau en application web pose plusieurs problèmes :
- Accès au matériel
- Appels de l'API Windows
- Gestion de l'état de l'application
- Accès au système de fichiers
- Contrôle d'accès
- Utilisation d'interfaces utilisateur/UX/contrôles spécifiques aux ordinateurs de bureau
Il existe des options pour convertir les applications de bureau de manière automatisée, qui permettent de convertir à la fois l'interface utilisateur et le code de l'application :
- http://www.codeproject.com/Articles/9307/Converting-WinForms-Web-Forms-using-CodeDom
- http://www.mobilize.net/webmap
- http://visualwebgui.com/ (n'existe apparemment plus)
Même si vous utilisez des outils de migration automatisés, vous devrez dans la plupart des cas effectuer un travail manuel important pour que l'application fonctionne de la même manière que l'application d'origine.
Certains de ces outils vous aideront à atteindre différents objectifs, le premier vous aidera à convertir uniquement l'interface utilisateur en WebForms, les deux derniers généreront ASP.NET MVC, l'un en utilisant un runtime personnalisé et un ensemble de bibliothèques et l'autre avec des bibliothèques HTML/JS/CSS courantes telles que Kendo MVVM, Kendo UI, AngularJS ou Bootstrap, entre autres. Ces outils fourniront une solution qui sera plus rapide que d'écrire l'application sur le web à partir de zéro et fourniront des solutions ou au moins des lignes directrices pour aborder les défis mentionnés précédemment. Cependant, il y aura quelques différences par rapport à une application conçue pour le web, simplement parce que les architectures sont différentes et que la façon d'écrire le code pour une application de bureau suppose des choses qui ne peuvent pas être assumées pour une application web.
Avertissement : je travaille pour Mobilize.Net, qui a créé WebMAP.
RogerG
Points
268
Just Someone
Points
1979
Juste un commentaire supplémentaire : la réécriture dépend de la quantité de logique contenue dans le formulaire lui-même. Avec des préoccupations correctement séparées, il ne s'agit que d'ajouter une autre interface utilisateur à la couche métier.
Le problème est, bien sûr, que 90% des applications ne sont rien de plus que des interfaces utilisateur CRUD quelque peu complexes (pas de véritable logique commerciale)...
