Класичний ASP до ASP.net або ASP.net MVC

У нас є веб-додаток, розроблений в класичному ASP, і воно розвивалося протягом 5 років до його теперішньої форми, яка містить 100 сторінок, величезну базу даних і більше 10000 активних користувачів, що проходять щонайменше понад 10 сторінок щодня.

Тепер ми хотіли оновити його до останньої версії .net. Спочатку ми думали переписати весь додаток, але, проаналізувавши сценарій, ми виявили, що це нежиттєздатний варіант, який також не пропонується багатьма експертами. Ми ще не визначилися, як це зробити в іншому випадку, але отримали кілька думок щодо того, як досягти переписування облич.

Варіант 1: Ми думали визначити основні модулі в цій програмі та переписати їх по черзі, розділивши додаток на різні шари, такі як база даних (існуюча), потім ділова логіка та представлення. Таким чином, нові розроблені модулі будуть додані до існуючої системи, а нові сторінки замінять старі сторінки в цьому конкретному модулі. У той же час ми можемо протестувати нові шари поряд зі старою системою та випустити їх, коли ми почуємо себе впевнено. Ми також думали розробити структуру API для бізнес-логіки, і це буде доступно для перегляду як зовнішньої програми.

Варіант 2: На даний момент ми зробили простий модуль і використовували його на класичній сторінці ASP через IFrame, хоча це було досить клопітно надсилати дані між класичним ASP та новою сторінкою в IFrame.

Це саме на етапі планування того, як нам слід досягти переписування всієї програми, не порушуючи базу користувачів.

Я хочу отримати погляди, думки та пропозиції інших програмістів щодо того, чи слід підходити до такого сценарію? якщо хтось стикався з подібним сценарієм, будь ласка, поділіться своєю думкою.

Також хотів би знати, що використання ASP.net MVC допоможе мені в цьому?

ОНОВЛЕННЯ : Дякую за обидві відповіді, що висловили свої погляди. Хочеться отримати більше вкладів щодо обох параметрів, зазначених вище, під час переміщення програми з класичного asp на asp.net або asp.net mvc. Було б дуже корисно для мене, якщо ви все зможете через ваші погляди, точки та думки щодо міграційної частини, а не з пункту вибору asp.net чи asp.net mvc.

Дозвольте розпочати, кажу: "Я відчуваю твій біль, брута". Я пережив це 3 роки тому, і я хотів би, щоб MVC дозрів на той момент, тому що розроблений нами проект WebForms досить добре нагадує модель MVC, не маючи насправді створених для мене бібліотек Microsoft (звичайно, було декілька яскравих "Чому чорт я зробив це "відмінності).

Я також закінчив використовувати iFrames для управління різницями вмісту, використовуючи .Net як батьківський додаток і класичний asp як підлеглий. Я розробив рамкову архітектуру в .Net і реалізував це. Класичні сторінки asp потім були "зібрані" з непотрібних фрагментів презентації (включає і те, що не потрібно) і завантажуються в iFrames. Далі дані передавались через URL-адресу за допомогою спеціального шифрування. Щоб переконатися в тому, що автентифікацію не вдалося легко підробити, а доступ до сторінки шляхом розтріскування рядка запиту, ми також застосували обробники Wildcard в IIS, які змусили .Net перевірити автентифікацію перед тим, як розбирати класичні сторінки asp.

Враховуючи це, моєю рекомендацією було б негайно звернутися до MVC.

1. MVC надасть вам доступ до маршрутизації на рівні global.asax. Завдяки розумному маніпулюванню контролером, ви могли б правильно розробити свої моделі та мати спільний контролер, який обробляє всі класичні запити asp за необхідності.
2. MVC зробить дуже простий додавання тестового проекту та дозволить переробляти окремі фрагменти додатків на основі нової структури моделі, забезпечуючи при цьому адекватне покриття тесту, щоб переконатися, що ви все встигаєте. Цінність цього абсолютно незрівнянна, оскільки в будь-якому коді рефактора охоплення викликає величезне занепокоєння.
3. MVC дотримується більш скриптизованого підходу до презентації, ніж WebForms. WebForms намагається змішати все це, мов це якесь велике застосування (яке це не так), і це може бути досить культурним шоком для людей, звикших до класичного аспіру. Не зрозумійте мене неправильно, ваші розробники зазнають культурного шоку незалежно від того, куди ви йдете, але якщо ви зможете винести певний шок із шару презентації, ви можете отримати більший успіх.

Мені подобаються як WebForms, так і MVC (хоча, я визнаю, із впровадженням Razor я став трохи упередженим щодо MVC). Вони обидва мають свої місця, і я думаю, що така програма, як описана вами, може бути ідеально підходить для реалізації MVC, особливо з огляду на "поетапний" характер, який вам потрібно буде прийняти при розгортанні реконструйованих фрагментів додатків.

Куди б ви не пішли, я думаю, що вам потрібно переконатися, що програма .Net завжди є батьківською програмою, коли справа стосується автентифікації / авторизації / маршрутизації / тощо. Мій колега здійснив свою міграцію за аналогічним додатком із класичним asp як батько, і у нього виникло велика кількість проблем, коли нарешті з'явилася можливість інтегрувати все назад разом.

Перехід на ASP.NET MVC не збирається полегшити перехід обов'язково, а насправді це може зробити його складніше. Однак, коли ви вже вирішили пройти цю грандіозну справу, чому б не витратити час, щоб продовжити та перейти на платформу, яка найкраще відповідає вашим планам?

Перехід на ASP.NET (sans MVC) буде "простішим" в тому сенсі, що ви, як правило, можете робити прямі порти вашої існуючої логіки без необхідності робити багато грандіозних рефакторингу, за умови, що ви не робите багато екзотичних речей класичний ASP. Результати будуть задовільними та відносно знайомими людям, які вже знайомі з програмою. Ви отримаєте переваги в тому сенсі, що кожна програма, що переноситься від класичного ASP до ASP.NET, отримує переваги .

Перехід на ASP.NET MVC буде більше роботи. Ймовірно, знадобиться перестановка вашої моделі програми, щоб вона відповідала схемі MVC . Це, як правило, гарна річ (тм), тому що це заохочує добру поведінку, як розділення проблем. Отримана програма, швидше за все, не буде нагадувати все, що у вас є, крім основних логічних фрагментів. Ви отримаєте й інші переваги . Це буде великим зрушенням культури, і знадобиться певна (пере) освіта команди розвитку, щоб зрозуміти, як правильно писати MVC.

Зауважимо, Microsoft не відмовляється від WebForms за версією ScottGu (станом на рік тому), але я не думаю, що це важко зробити дзвінок, що якщо / коли вони вирішать припинити одну з цих двох технологій, це буде Веб-форми.

Я повністю згоден, що ASP.NET MVC - це шлях. Це буде непросто, не буде простіше, але це, безумовно, набагато більше доказів у майбутньому, ніж WebForms. Хоча WebForms, безумовно, не відмовилися, додатки, що використовують їх, стають все більш громіздкими для людей, оскільки додатки стають все більшими та більшими.

Я рішуче перешкоджаю використанню WebForms у "великих" додатках.

Мені подобається Варіант 1) (з MVC) набагато кращий, ніж Варіант 2), оскільки він дозволяє еволюціонувати додаток поступово, при цьому не потрібно з’єднувати два додатки занадто сильно, як це було б із підходом iFrames.

Я мав певний досвід перенесення старого додатка на ASP.Net, і однією з проблем було обмін деякими ресурсами, такими як стан сеансу між двома програмами. Це можна вирішити, якщо одне додаток викликає інше на стороні сервера через інформацію про cookie з браузера користувача. Інший обмін інформацією між додатками можна, звичайно, також здійснювати за допомогою маршрутизації URL-адрес та рядків запитів, що є природним підходом до MVC.

Також визначити відповідні модулі для міграції спочатку може бути складним завданням, але ви можете почати з того, що на MVC розробляється нова функціональність, щоб запобігти міграції більшої кількості речей у гаражі. Тоді, можливо, виберіть розділи, які мають значні відставання у переробці чи виправлення помилок, які слід виконати далі, оскільки додаток MVC стане формою рефакторингу, використовуючи вашу стару систему для встановлення очікуваних результатів, як ви пропонуєте. Не забудьте також скористатися перевіркою MVC, додавши під час цього рефакторингу модульні тести та автоматичні тести приймання (наприклад, SpecFlow / Watin). Однією з переваг останнього типу тестів є те, що ви можете переконатися, що вони проходять стару систему, а потім застосувати ті ж тести до нового коду для цього та майбутніх рефакторингах.