ASP.net 또는 ASP.net MVC에 대한 클래식 ASP

우리는 클래식 ASP로 개발 된 웹 애플리케이션을 보유하고 있으며 5 년에 걸쳐 현재의 형태로 100 페이지, 거대한 데이터베이스 및 하루에 10 페이지 이상을 처리하는 10000 명 이상의 활성 사용자가있는 현재 형태로 진화했습니다.

이제 최신 버전의 .net으로 업그레이드하려고했습니다. 처음에는 전체 앱을 다시 작성하려고 생각했지만 시나리오를 분석 한 후 실행 가능한 옵션이 아니라는 것이 많은 전문가들에게도 제안되지 않았습니다. 우리는 아직 어쨌든 어떻게 할 것인지 결정하지 않았지만 얼굴을 다시 쓰는 방법에 대해 몇 가지 생각을했습니다.

옵션 1 : 이 응용 프로그램에서 기본 모듈을 식별하고 응용 프로그램을 데이터베이스 (기존), 비즈니스 논리 및보기와 같은 다른 계층으로 분리하여 하나씩 다시 작성하려고했습니다. 이렇게하면 새로 개발 된 모듈이 기존 시스템에 추가되고 새 페이지가 해당 특정 모듈의 이전 페이지를 대체합니다. 동시에 기존 시스템과 함께 새 레이어를 테스트하고 자신감이 있으면 릴리스 할 수 있습니다. 우리는 또한 비즈니스 로직을위한 API 종류의 구조를 개발하려고 생각했으며 외부 애플리케이션으로 볼 수 있습니다.

옵션 2 : 현재 우리는 간단한 모듈을 만들어 IFrame을 통해 클래식 ASP 페이지에서 사용했지만, 클래식 ASP와 IFrame의 새 페이지간에 데이터를 전송하는 것은 상당히 번거로운 일이었습니다.

이것은 사용자 기반을 방해하지 않고 전체 응용 프로그램을 다시 작성하는 방법에 대한 계획 단계에 있습니다.

그런 시나리오에서 다른 프로그래머의 견해, 의견 및 제안을 받고 싶습니다. 이런 종류의 시나리오에 직면 한 사람이 있다면 의견을 공유하십시오.

또한 ASP.net MVC를 사용하면이 점에서 나를 도울 것입니다.

업데이트 : 귀하의 견해를 밝힌 두 가지 답변에 감사드립니다. 클래식 asp에서 asp.net 또는 asp.net mvc로 응용 프로그램을 마이그레이션 할 때 위에서 지정한 옵션 모두에 대해 더 많은 입력을 원합니다. asp.net 또는 asp.net mvc를 선택하는 것이 아니라 마이그레이션 부분에 대한 견해, 요점 및 생각을 모두 이해할 수 있다면 큰 도움이 될 것입니다.

"나는 당신의 고통을 느낍니다." 저는 3 년 전에이 과정을 거쳤습니다. 제가 디자인 한 WebForms 솔루션이 실제로 Microsoft 라이브러리를 구축하지 않고도 MVC 모델과 상당히 유사하기 때문에 MVC가 그 시점에서 성숙해 졌기를 바랍니다. 내가 그랬어 "차이).

또한 .Net을 부모 응용 프로그램으로 사용하고 클래식 ASP를 슬레이브로 사용하여 콘텐츠 차이를 관리하기 위해 iFrames를 사용했습니다. .Net에서 프레임 워크 아키텍처를 개발하고 구현했습니다. 그런 다음 클래식 ASP 페이지는 불필요한 프리젠 테이션 조각 (포함 및 기타 포함)을 "수집"하여 iFrame에로드했습니다. 그런 다음 사용자 지정 암호화를 사용하여 URL을 통해 데이터를 전달했습니다. 인증을 쉽게 스푸핑 할 수없고 쿼리 문자열을 크래킹하여 페이지에 액세스 할 수 있도록 IIS의 와일드 카드 처리기를 사용하여 .Net이 클래식 ASP 페이지를 구문 분석하기 전에 인증하도록했습니다.

그것을 감안할 때, 나의 추천은 바로 MVC로 향하는 것입니다.

1. MVC는 global.asax 수준에서 라우팅에 대한 액세스를 제공합니다. 컨트롤러를 영리하게 조작하면 모델을 적절한 방식으로 개발할 수 있으며 필요에 따라 모든 클래식 ASP 요청을 처리하는 공통 컨트롤러를 가질 수 있습니다.
2. MVC를 사용하면 테스트 프로젝트를 매우 간단하게 추가하고 새로운 모델 구조를 기반으로 개별 애플리케이션을 리팩토링 할 수있을뿐만 아니라 적절한 테스트 범위를 제공하여 모든 작업을 올바르게 수행 할 수 있습니다. 리 팩터 코드 적용 범위에 큰 관심이 있기 때문에 이것의 가치는 절대로 계산할 수 없습니다.
3. MVC는 WebForms보다 더 많은 스크립트 방식의 프리젠 테이션 방식을 따릅니다. WebForms는 일종의 상태 저장 응용 프로그램 (그렇지 않은)처럼 모든 것을 혼합하려고 시도하며 이는 고전적인 ASP에 익숙한 사람들에게는 상당히 문화적 충격이 될 수 있습니다. 나를 잘못 생각하지 마십시오. 개발자는 어떤 방식 으로든 문화 충격을받을 것입니다. 그러나 프레젠테이션 레이어에서 충격을받을 수 있다면 더 큰 성공을 거둘 수 있습니다.

나는 WebForms와 MVC를 모두 좋아한다 (Razor의 도입으로 MVC에 약간 편향되고 있음을 인정하지만). 그들은 둘 다 자신의 위치를 ​​가지고 있으며, 당신이 설명하는 것과 같은 응용 프로그램은 특히 리팩토링 된 응용 프로그램을 롤아웃 할 때 채택해야 할 "스 태거 (staggered)"특성을 고려하여 MVC 구현에 이상적으로 적합 할 수 있다고 생각합니다.

어떤 방법을 사용하든 .Net 응용 프로그램이 인증 / 권한 부여 / 라우팅 / 기타와 관련하여 항상 부모 응용 프로그램인지 확인해야한다고 생각합니다. 내 동료는 부모와 같은 고전적인 ASP를 사용하여 유사한 응용 프로그램에서 마이그레이션을 구현했으며 마침내 모든 것을 다시 통합하는 데 많은 문제가있었습니다.

ASP.NET MVC를 사용한다고해서 전환이 더 쉬워지는 것은 아니며 실제로 더 어려워 질 수 있습니다. 그러나 이미이 위대한 사업을 수행하기로 결정했을 때 시간을내어 계획에 가장 적합한 플랫폼으로 옮기는 것이 어떻습니까?

ASP.NET (sans MVC)으로의 마이그레이션은 일반적으로 많은 리팩토링을하지 않고도 기존 로직의 포트를 직접 사용할 수 있다는 의미에서 "더 쉬워 질 것"입니다. 고전적인 ASP. 결과는 이미 응용 프로그램에 익숙한 사람들에게 만족스럽고 비교적 친숙 할 것입니다. 당신은 의미에서 이점을 얻을 수 있습니다 ASP.NET 혜택을 수신에 모든 응용 프로그램은 기존 ASP에서 포팅 .

ASP.NET MVC로 마이그레이션하는 것이 더 많은 작업이 될 것입니다. MVC 패턴 에 맞게 애플리케이션 모델을 재구성해야 할 수도 있습니다 . 이것은 일반적으로 Good Thing (tm)으로, 우려 분리와 같은 우수한 행동을 권장하기 때문입니다. 결과 응용 프로그램은 핵심 논리 부분을 제외하고는 기존의 내용과 거의 유사하지 않습니다. 다른 장점도 얻을 수 있습니다 . 그것은 큰 문화 변화가 될 것이며 "MVC 작성법"을 제대로 이해하기 위해서는 개발팀의 (재) 교육이 필요합니다.

참고로, Microsoft는 ScottGu에 따르면 (1 년 전) WebForms를 포기 하지는 않지만,이 두 기술 중 하나를 단계적으로 결정하기로 결정한 경우에는 전화를 걸기가 어렵다고 생각하지 않습니다. WebForms.

ASP.NET MVC가 좋은 방법이라는 데 전적으로 동의합니다. 쉽지는 않지만 쉽지는 않지만 WebForms보다 훨씬 더 미래의 증거입니다. WebForms는 확실히 포기되지 않았지만, 애플리케이션이 점점 커짐에 따라 WebForms를 사용하는 애플리케이션의 관리가 점점 번거로워지고 있습니다.

"큰"응용 프로그램에서 WebForms를 사용하지 않는 것이 좋습니다.

iFrames 접근 방식과 같이 두 앱을 너무 많이 연결할 필요없이 옵션 1) (MVC 사용)이 옵션 2보다 훨씬 낫습니다.

이전 앱을 ASP.Net으로 마이그레이션 한 경험이 있으며 두 앱간에 세션 상태와 같은 리소스를 공유하는 것이 어려웠습니다. 이는 한 브라우저에서 쿠키 정보를 통해 서버 측에서 하나의 앱이 다른 앱을 호출하도록하여 해결할 수 있습니다. 물론 앱 간의 다른 정보 공유는 URL 라우팅 및 쿼리 문자열을 통해 수행 될 수 있으며 이는 MVC와의 자연스러운 접근 방식입니다.

또한 먼저 마이그레이션 할 적절한 모듈을 식별하는 것이 어려울 수 있지만 MVC에서 개발 된 모든 새로운 기능으로 시작하여 차고에서 더 많은 항목이 마이그레이션되지 않도록 할 수 있습니다. 그런 다음 MVC 앱이 기존 시스템을 사용하여 제안한대로 예상 결과를 설정하는 리팩토링의 형태가되므로 다음에 수행해야 할 재 작업 또는 버그 수정에 대한 백 로그가 많은 섹션을 선택하십시오. 이 리팩토링 중에 단위 테스트 및 자동 수락 테스트 (예 : SpecFlow / Watin)를 추가하여 MVC의 테스트 가능성을 활용하는 것도 잊지 마십시오. 후자의 테스트 유형의 한 가지 장점은 이전 시스템을 통과했는지 확인한 다음이 코드와 향후 리팩토링을 위해 동일한 코드를 새 코드에 적용 할 수 있다는 것입니다.