MVC в C # сосуществует с Webforms в VB.Это может случиться?

Question

Я унаследовал действительно ужасное приложение веб-форм, которое является всевозможным плохим - непроверяемый волосатый беспорядок наборов данных и событий Page_Load.Объектно-ориентированный?N-уровня?Модульные тесты?управления источником?Все академические тонкости для команды, которая создала этот беспорядок.

Это начало жизни как классическое приложение для asp, в основном портированное на VB.NET.Руководство отклонило мою просьбу «уничтожить весь сайт с орбиты» и начать все сначала.

[Вставьте дискурс о том, что ASP.NET MVC, безусловно, является единственным разумным способом больше не заходить на сайты .net],Вопрос в том, можем ли мы оставить унаследованный код в VB и создать новый материал на C #?Я хочу форсировать переход на C #, чтобы команда не впала в вредные привычки.

Есть ли стратегия MVC 2 Areas, которую мы могли бы использовать здесь?

Answer 1

Я не удивлен, что идея полного переписывания была сбита. В общем, это рецепт для задержки и большего количества ошибок, независимо от того, насколько глючит текущий проект.

Насколько я знаю, это зависит от типа проекта. Если существующий проект представляет собой веб-приложение, то нет, вы не можете. Вы можете ссылаться на внешние библиотеки, встроенные в C # из-за CLR, однако вы не сможете запечь код C # прямо в проекте. Это делается постоянно и в основном приемлемо.

Если существующий проект является проектом веб-сайта, то я бы сказал, что да, вы можете. Однако вы не должны охотно делать это, если в этом нет абсолютной необходимости. Это просто требует сложного сопровождения проекта и, по сути, требует от вас много управления в web.config. Я настоятельно рекомендую не делать этого.

ссылка на сайт: http://timheuer.com/blog/archive/2007/02/28/14002.aspx

Я думаю, вы должны уметь использовать этот метод вместе с поисковыми системами Google, упомянутыми в предыдущем постере. Это займет немного работы, хотя.

Кроме того, практика кодирования в значительной степени не связана с языком, и, исходя из моего опыта работы в основном с веб-формами и небольшим MVC, оба имеют свое время и место. Я бы посмотрел на установление набора практик, которые должны соблюдаться, и применял их с помощью обзоров кода. Любой новый код, который вы пишете, будет содержаться в чистоте и сохранности, в то время как вы также можете обновить старый код для использования стандартов.

Answer 2

Это возможно, по сути, сделать встраиваемыми все представления и т. Д. В проекте MVC, добавить его в качестве ссылки на проект VB.Net и затем зарегистрировать маршруты.

Это немного сложнеевот что, у Мэтта Ханикатта есть серия постов, в общих чертах описывающих, как он это сделал:

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

Answer 3

Меня заинтриговало ваше предположение, что вредные привычки команды вызваны использованием VB. На любом языке есть много вредных привычек: дело не в том, чтобы переключить язык, а в том, чтобы выучить хорошие.

Любой пост о подобных вещах будет мнением, и, на мой взгляд, вам лучше научить их правильно программировать на VB, чем заставлять их изучать новый язык, с которым они могут бороться. Я видел отличный, стабильный, обслуживаемый код VB и ужасный, грязный код на C #. Старайтесь не связывать язык программирования с качеством вывода команды, которая его использует.

(Кстати, я разрабатываю как на VB, так и на C # и всегда выбираю C #, учитывая выбор - но не потому, что я думаю, что я пишу лучший код на C #.)