Очистка сложного проекта WebForms

Question

В настоящее время я работаю над поисковым онлайн-сайтом с большим трафиком.

У них есть различные изменения, которые они хотят реализовать с течением времени, и они указали, что, в конечном счете, они хотят, чтобы сайт был заново выполнен в ASP.NET MVC.

В настоящее время сайт является проектом ASP.NET WebForms; однако настоящие элементы управления ASP.NET используются редко. Вместо этого есть много серверных тегов - то есть <% ...%>. Код в этих тегах обычно представляет собой вызов статического метода в статическом классе или фрагмент кода C #, который генерирует HTML.

Многие из статических методов генерируют HTML, добавляя текст в конструктор строк и возвращая его в виде строки.

Я понимаю концепцию вспомогательного метода, но мне не нравится идея рендеринга HTML-кода путем его конкатенации в строковую переменную. Я думаю, им было бы лучше использовать «Partials».

Меня беспокоит то, что это довольно сложный сайт, и я не уверен, хорошая ли полная перестройка сайта в ASP.NET MVC.

Несмотря на плохую структуру, добавить новые запрашиваемые функции не так уж сложно. (Возможно, потому что у меня был опыт работы со сложным кодом).

Однако я думаю, что есть риск, что когда-нибудь в будущем появится требование, которое будет очень трудно реализовать, если мы не выполним полную очистку базы кода.

Я хочу поставить этот вопрос там и посмотреть, сталкивался ли кто-нибудь с подобной проблемой, и как вы справились с ней.

Кроме того, что вы думаете о том, чтобы сделать перестройку как 20% -ный сторонний проект? Есть ли минусы в этом?

Answer 1

Ух ты, это какой-то проект.

Лично я думаю, что любой сайт, написанный на ASP.Net, должен быть полностью переработан, если говорить об интерфейсе пользователя. MVC делает это совсем по-другому.

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

Доступ к данным должен быть в порядке и, вероятно, требует минимального касания. Но это опять-таки зависит от того, насколько тесно связан ваш веб-сайт.

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

Получите ваш фундамент на месте и, возможно, даже, если возможно, уже используйте инфраструктуру MVC. Опять же, только если вы можете и только если это жизнеспособно.

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

Но помните, что после преобразования проекта / слоя, который вы (делаете), реализуете его, он рискует быть забытым или внести изменения в другой слой, которые затем необходимо кодировать в новый и т. Д. знать ловушки.

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

Если в вашем коде много кода, вы можете начать перемещать его на другой уровень, так как это поможет позже при создании контроллеров и т. Д. Затем они могут создать экземпляр вашего нового слоя, и все будет хорошо.

Это все, что я могу думать с макушки головы. Я буду редактировать или комментировать, как я думаю о вещах.

Надеюсь, это поможет.

Answer 2

Если у меня есть этот проект, и меня попросили повторить его с нуля, я не буду использовать MVC для визуализации пользовательского интерфейса, я буду использовать Web API / OData для размещения всего бэкэнда и буду использовать любой хороший интерфейс для рисования пользовательский интерфейс, Angular будет очень хорошим вариантом.

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

Кроме того, вы должны учитывать любую миграцию данных, если вам придется изменить параметр хранения данных.