MVC en C# coexistant avec Webforms dans VB. Cela peut-il arriver?

Question

J'ai hérité d'une application webforms vraiment horrible qui est de toutes sortes de mauvaises - un désordre intempestif de jeux de données et d'événements Page_Load. Objet orienté? N-tier? Tests unitaires? contrôle de la source? Toutes les finesses académiques à l'équipe qui a construit ce désordre.

Il a commencé sa vie comme une application classique d'asp, principalement porté sur VB.NET. La direction a refusé ma demande de "nuke l'ensemble du site de l'orbite" et recommencer.

[Insérer le discours sur la façon dont ASP.NET MVC est absolument, positivement la seule façon saine de .NET sites plus]

Je sais que nous pourrions être en mesure d'interopérer entre les anciens et webforms mvc. La question est, pouvons-nous laisser le code existant dans VB et construire le nouveau contenu en C#? Je veux forcer la conversion en C# afin que l'équipe ne retombe pas dans de mauvaises habitudes.

Y a-t-il une stratégie MVC 2 Areas que nous pourrions utiliser ici?

Answer 1

Je suis intrigué par votre implication que les mauvaises habitudes de l'équipe sont causées par l'utilisation de VB. Il y a beaucoup de mauvaises habitudes dans n'importe quelle langue: l'astuce n'est pas de changer de langue, mais d'apprendre de bonnes habitudes. Le message de tout le monde sur ce genre de chose va être l'opinion - et à mon avis, vous feriez mieux de leur apprendre à programmer correctement dans VB que de leur faire apprendre une nouvelle langue avec laquelle ils peuvent lutter. J'ai vu un code VB génial, stable et maintenable et j'ai vu un code C# horrible et désordonné. Essayez de ne pas associer un langage de programmation à la qualité de la production d'une équipe qui l'utilise.

(Pour mémoire, je développe à la fois VB et C# et serait toujours choisir C# étant donné le choix - mais pas parce que je pense que j'écrire un meilleur code en C#.)

Answer 2

Je ne suis pas surpris l'idée de une réécriture totale a été abattu. En général, c'est une recette pour le retard et plus de bugs, quel que soit le buggy du projet actuel. Pour autant que je sache, cela dépend du type de projet. Si le projet existant est une application web, alors non vous ne pouvez pas. Vous pouvez référencer des bibliothèques externes construites en C# à cause du CLR, cependant, vous ne serez pas capable de faire du code C# directement dans le projet. Ceci est fait tout le temps et est la plupart du temps acceptable.

Si le projet existant est un projet de site Web alors je devrais dire oui vous pouvez. Cependant, vous ne devriez pas le faire volontairement à moins qu'il y ait un besoin absolu de le faire. Cela demande simplement un projet difficile à maintenir et vous oblige essentiellement à faire beaucoup de gestion dans le web.config. Je déconseille fortement de le faire.

référence du site: http://timheuer.com/blog/archive/2007/02/28/14002.aspx

Je pense que vous devriez être en mesure de mettre cette méthode en même temps que ceux de la recherche Google mentionné par une affiche plus tôt. Cela va prendre un peu de travail si.

En outre, les pratiques de codage sont à peu près sans rapport avec le langage et, d'après mon expérience de travail avec des formulaires Web et un peu de MVC, les deux ont leur temps et leur place. Je chercherais à établir un ensemble de pratiques à suivre et à les appliquer en utilisant des révisions de code. Tout nouveau code que vous écrivez sera maintenu propre et serré alors que vous pouvez également mettre à jour l'ancien code pour utiliser les normes.

Answer 3

Il est possible, essentiellement en intégrant toutes les vues, etc. dans le projet MVC, de l'ajouter comme référence au projet VB.Net, puis d'enregistrer les routes.

Il est un peu plus compliqué que cela, Matt Honeycutt a une série de messages décrivant à peu près comment il a fait ici:

http://trycatchfail.com/blog/post/ASPNET-MVC-3-Razor-C-and-VBNET-WebForms-A-Tale-of-Black-Magic-Voodoo.aspx