Klasyczna ASP do ASP.net lub ASP.net MVC

Mamy aplikację internetową, która jest rozwijana w klasycznej ASP i ewoluowała w ciągu 5 lat do obecnej formy, która ma 100 stron, ogromną bazę danych i ponad 10000 aktywnych użytkowników przeglądających co najmniej ponad 10 stron dziennie.

Teraz chcieliśmy uaktualnić go do najnowszej wersji .net. Początkowo myśleliśmy o przepisaniu całej aplikacji, ale po przeanalizowaniu scenariusza stwierdziliśmy, że nie jest to realna opcja, również nie sugerowana przez wielu ekspertów. Nie zdecydowaliśmy jeszcze, jak to zrobić w inny sposób, ale zastanowiliśmy się, jak uzyskać przepisywanie twarzy.

Opcja 1: Pomyśleliśmy o zidentyfikowaniu głównych modułów w tej aplikacji i przepisaniu ich jeden po drugim poprzez podzielenie aplikacji na różne warstwy, takie jak baza danych (istniejąca), następnie logika biznesowa i widok. W ten sposób nowo opracowane moduły zostaną dodane do istniejącego systemu, a nowe strony zastąpią stare strony w tym konkretnym module. Jednocześnie możemy przetestować nowe warstwy wraz ze starym systemem i zwolnić je, gdy będziemy mieć pewność. Zastanawialiśmy się również nad stworzeniem struktury API dla logiki biznesowej i będzie ona dostępna jako widok aplikacji zewnętrznej.

Opcja 2: W tej chwili stworzyliśmy prosty moduł i użyliśmy go na klasycznej stronie ASP przez ramkę IFrame, chociaż wysyłanie danych między klasyczną ASP a nową stroną w ramce IF było dość kłopotliwe.

To jest właśnie na etapie planowania, w jaki sposób powinniśmy przepisać całą aplikację bez naruszania bazy użytkowników.

Chcę uzyskać opinie innych programistów, opinie i sugestie dotyczące tego, czy powinniśmy podejść do takiego scenariusza? jeśli ktoś spotkał się z tego rodzaju scenariuszem, podziel się swoją opinią.

Chciałbym również wiedzieć, że korzystanie z ASP.net MVC pomoże mi w tym?

AKTUALIZACJA : Dziękujemy za odpowiedzi na oba pytania. Chciałbym uzyskać więcej danych wejściowych dla obu opcji, które określiłem powyżej, migrując aplikację z klasycznego asp do asp.net lub asp.net mvc. Byłoby to dla mnie wielką pomocą, jeśli wszyscy moglibyście przejrzeć swoje poglądy, uwagi i przemyślenia na temat migracji, a nie cel wyboru asp.net lub asp.net mvc.

Zacznę od stwierdzenia: „Czuję twój ból, brutha”. Przeszedłem przez to 3 lata temu i żałuję, że MVC nie dojrzał w tym momencie, ponieważ zaprojektowane przeze mnie rozwiązanie WebForms dość dobrze przypomina model MVC bez faktycznej budowy bibliotek Microsoft (oczywiście było kilka rażących „Dlaczego do diabła”) zrobiłem to „różnice).

Skończyło się również na użyciu ramek iFrames do zarządzania różnicami w zawartości, używając .Net jako aplikacji nadrzędnej i klasycznego asp jako urządzenia podrzędnego. Opracowałem architekturę ramową w .Net i zaimplementowałem ją. Klasyczne strony asp zostały następnie „zbite” z niepotrzebnych elementów prezentacji (zawiera i co tam jeszcze) i załadowano do iFrame. Dane były następnie przekazywane przez adres URL przy użyciu niestandardowego szyfrowania. Aby upewnić się, że uwierzytelnienie nie może być łatwo sfałszowane i dostęp do strony przez złamanie ciągu zapytania, zastosowaliśmy również procedury obsługi symboli wieloznacznych w IIS, które zmusiły .Net do uwierzytelnienia przed analizą klasycznych stron asp.

Biorąc to pod uwagę, polecam od razu udać się do MVC.

1. MVC zapewni ci dostęp do routingu na poziomie global.asax. Dzięki sprytnej manipulacji kontrolerem możesz opracować swoje modele we właściwy sposób i mieć wspólny kontroler, który obsługuje wszystkie klasyczne żądania asp w razie potrzeby.
2. MVC bardzo ułatwi dodanie projektu testowego i pozwoli na refaktoryzację poszczególnych elementów aplikacji w oparciu o nową strukturę modelu, zapewniając jednocześnie odpowiedni zakres testów, aby upewnić się, że wszystko jest w porządku. Wartość tego jest absolutnie nieobliczalna, ponieważ w każdym kodzie refaktora pokrycie problemu jest ogromnym problemem.
3. MVC stosuje bardziej skrypty podejście do prezentacji niż WebForms. WebForms stara się to wszystko pomieszać, jakby to była jakiś stanowa aplikacja (której nie ma), co może być szokiem kulturowym dla osób przyzwyczajonych do klasycznego bolenia. Nie zrozum mnie źle, Twoi programiści przeżyją szok kulturowy bez względu na to, którą drogę wybierzesz, ale jeśli uda Ci się usunąć część tego szoku z warstwy prezentacji, możesz odnieść większy sukces.

Lubię zarówno WebFormy, jak i MVC (choć przyznam, że wraz z wprowadzeniem Razor, jestem trochę stronniczy w stosunku do MVC). Obaj mają swoje miejsca i myślę, że aplikacja taka jak ta, którą opisujesz, może idealnie nadawać się do implementacji MVC, szczególnie biorąc pod uwagę „rozłożoną” naturę, którą musisz przyjąć przy wdrażaniu zrestrukturyzowanych elementów aplikacji.

Niezależnie od tego, którą drogą wybierzesz, uważam, że musisz upewnić się, że aplikacja .Net jest zawsze aplikacją nadrzędną, jeśli chodzi o uwierzytelnianie / autoryzację / routing / itp. Mój kolega wdrożył swoją migrację na podobnej aplikacji z klasycznym boleniem jako rodzic, i miał wiele problemów, gdy w końcu przyszło zintegrować wszystko z powrotem.

Przejście na ASP.NET MVC niekoniecznie ułatwi przejście, a może w rzeczywistości może utrudnić. Jeśli jednak zdecydowałeś się już przejść przez to wielkie przedsięwzięcie, dlaczego nie poświęcić czasu i przejść na platformę, która najlepiej pasuje do twoich planów?

Migracja do ASP.NET (bez MVC) będzie „łatwiejsza” w tym sensie, że ogólnie możesz wykonywać proste porty istniejącej logiki bez konieczności przeprowadzania dużego refaktoryzacji, pod warunkiem, że nie robisz wielu egzotycznych rzeczy z klasyczna ASP. Wyniki będą zadowalające i stosunkowo znane osobom, które już znają aplikację. Osiągniesz korzyści w tym sensie, że każda aplikacja przeniesiona z klasycznej ASP do ASP.NET otrzymuje korzyści .

Migracja do ASP.NET MVC będzie wymagać więcej pracy. Prawdopodobnie będzie to wymagać ponownej analizy modelu aplikacji w celu dopasowania do wzorca MVC . Jest to na ogół Dobra Rzecz (TM), ponieważ zachęca do dobrych zachowań, takich jak rozdzielanie obaw. Wynikowa aplikacja najprawdopodobniej nie będzie przypominać niczego, co istnieje, z wyjątkiem podstawowych elementów logicznych. Otrzymasz również inne zalety . To będzie wielka zmiana kultury i zajmie trochę (re) edukacji zespołu programistów, aby zrozumieć „jak pisać MVC” poprawnie.

Warto zauważyć, że Microsoft nie rezygnuje z WebForms według ScottGu (jak rok temu), ale nie sądzę, że trudno jest zadzwonić, że jeśli / kiedy zdecydują się wycofać jedną z tych dwóch technologii, będzie to Formularze internetowe.

Całkowicie się zgadzam, że ASP.NET MVC jest właściwą drogą. To nie będzie łatwe, nie będzie łatwiejsze, ale z pewnością jest o wiele bardziej przyszłościowe niż WebForms. Podczas gdy WebForms z pewnością nie zostało porzucone, aplikacje, które z nich korzystają, stają się coraz trudniejsze do utrzymania, gdy aplikacje stają się coraz większe.

Zdecydowanie odradzam korzystanie z formularzy internetowych w „dużych” aplikacjach.

Podoba mi się opcja 1) (z MVC) znacznie lepsza niż opcja 2), ponieważ pozwala ona na stopniową ewolucję aplikacji, bez konieczności łączenia dwóch aplikacji zbyt mocno, jak w przypadku podejścia iFrames.

Miałem trochę doświadczenia z migracją starej aplikacji do ASP.Net, a jednym z wyzwań było współdzielenie niektórych zasobów, takich jak stan sesji między dwiema aplikacjami. Można to rozwiązać przez wywołanie jednej aplikacji po stronie serwera za pośrednictwem informacji o plikach cookie z przeglądarki użytkownika. Inne dzielenie się informacjami między aplikacjami może oczywiście odbywać się również poprzez routing URL i ciągi zapytań, co jest naturalnym podejściem w MVC.

Identyfikacja odpowiednich modułów do migracji w pierwszej kolejności może być wyzwaniem, ale możesz zacząć od opracowania wszystkich nowych funkcji w MVC, aby zapobiec migracji większej liczby rzeczy do garażu. Następnie może wybierz sekcje, które mają znaczące zaległości w zakresie przeróbek lub poprawek błędów, które należy wykonać, ponieważ aplikacja MVC stałaby się wówczas formą refaktoryzacji, używając starego systemu do ustalenia oczekiwanych rezultatów, jak sugerujesz. Nie zapomnij również skorzystać z możliwości testowania MVC poprzez dodanie testów jednostkowych i automatycznych testów akceptacyjnych (np. SpecFlow / Watin) podczas tego refaktoryzacji. Jedną z zalet tego ostatniego typu testów jest to, że można zweryfikować, czy przekazują one stary system, a następnie zastosować te same testy do nowego kodu dla tego i przyszłych refaktoryzacji.