Webform에서 MVC로 전환하는 이유

앞으로 몇 년 동안Web form 사용이 점차 줄어들 것이고 대신 MVC가 될 것이라고 할 수 있다.아마도 네가 나의 관점에 동의하지 않을 것이다. 그러면 나는 나의 관점을 논술해 보겠다. 만약 네가 여전히 받아들일 수 없다면, 네가 나를 반박해 보아라.
새로운 언어나 구조를 배우는 데는 시간이 필요하다. 우리는 원래 깊이 있게 공부하고 숙련된 구조를 버리고 새로운 구조에 영합해야 하는가?그렇습니다. 만약에 제 대답이 맞다면 이 새로운 구조가 도대체 원래의 구조와 어떤 개선이 있는지 똑똑히 보아야 합니다. 정말 우리가 많은 시간을 들여 공부해야 합니까?Mvc는 일종의 구조 모델로 ASp시대와 같은 새로운 개발 체험을 가져왔다.
다음은 Web form,MVC에 대해 우리가 배울 가치가 있는지를 논술하겠습니다.
1.View State
여러분이 이 보기 상태에 대해 잘 알고 계신다고 믿습니다. 이것은 우리가 페이지에 입력한 데이터 상태를 저장하는 데 사용됩니다. 우리가 페이지를 새로 고치거나 보낼 때 페이지를 원래의 입력 데이터로 되돌릴 수 있도록 하는 데 사용됩니다. 이 효과는 우리의 수요를 잘 실현시켰습니다.그러나 동시에 우리는 자신에게 이런 것들이 정말 필요한지, 페이지를 새로 고칠 때 원래의 데이터를 표시해야 하는지 물어봐야 한다. 이것은 의미가 있는가?
그리고 View State 시대에 크게 유행하여 모든 페이지에 존재했다. 심지어 복잡한 페이지에서 그의 크기가 매우 커서 매번 페이지가 반송될 때마다 View State 상태를 전달했다. 우리는 서버가 이런 View State를 해석하는 데 필요할 때를 말하지 않고 매번 페이지 전송할 때마다 이런 View State를 전달하면 대역폭이 증가한다.웹 페이지를 표시하는 시간이 길어집니다.이것은 2.0시대에 적어도 내가 허락하지 않았던 것이다.
2. 페이지 라이프 사이클web form에는 복잡한 생명주기가 존재한다. 나는 심지어 내가 웹 폼을 배울 때 종이에 펜을 들고 이 주기도를 그렸고 매 주기 페이지에서 어떤 동작을 하는지 똑똑히 기억한다.이것은 마치 내가 c#연결 데이터베이스를 공부할 때Web form쓰는 것과 같아서 나를 매우 골치 아프게 한다.예를 들어 sql helper에서 구체적인 컨트롤에 접근해서는 안 된다. 왜냐하면 이 컨트롤이 아직 생성되지 않았기 때문이다. (원우가 오류를 제기했기 때문에 자료를 찾아보았는데 이것도 잘못된 것이라고 생각했다. 왜냐하면 이때 컨트롤을 출력하려고 과장했기 때문이다. 이에 성명한다. 원우가 오류를 제기해 주셔서 감사합니다. 적극적으로 고치겠습니다) 방문하려면 Page_render()에서우리는 매일 Page_load()사건과 접촉해야 하는데, 적어도 나는 매우 자주 접촉한다.Page_Load()는 흔히 볼 수 있는 방법이다.
만약 네가 이 생명주기들을 완전히 파악할 수 있다고 생각한다면, 적어도 너는 큰 소일 것이다.만약 당신이 페이지의 생명 주기를 마음대로 제어하고 컨트롤의 생성을 제어할 수 있다면, 나는 당신을 매우 존경할 것입니다.
3. False sense of concerns 실패의 관심사 분리
현재 우리가 소프트웨어를 만들 때 중시하는 것은 모두 유지보수성, 중용성, 관심사 분리이다.이별에 관심을 갖는 이유는 각 층의 구조가 그 자신의 일만 책임지고 그의 통제불능이 아니며 통제하려 하지 않는다는 것이다.예를 들어 우리는 IsPostBack에 데이터베이스에 접근하는 코드를 쓰고 code behind의 클래스를 호출했지만 현재 데이터베이스 서버의 서비스가 열리지 않았기 때문에 이번 호출은 틀림없이 이상을 던질 것이다.설마 우리sql helper에서 이런 이상을 처리하라고 한다면 우리 프로그래머는 피곤해 죽을 것이다. 이상은 code behind에서 처리하는 것이지 sql helper에서 처리하는 것이 아니다.이른바 관심사 분리일 것이다.그리고 관심사 분리는 모든 종류가 자신의 업무만 책임지고 한 종류code behind에 되돌아오는 문구가 나타나지 않도록 해야 한다.
4. Limited control over HTML은 html에 대한 제어가 매우 떨어진다.
나는 페이지의 생명주기에서 생성된 컨트롤을 마음대로 변경할 수 있다면 당신을 숭배할 것이라고 말했다.만약에 서버 사이드 컨트롤러가 html을 생성하는 스타일을 제어하거나 html의 ID,name을 생성하여 js가 사용할 수 있도록 한다면 이것은 매우 어려운 것이다.그럼요.net4.0에 속성이 추가되었습니다. 바로 Sql Helper입니다. 이 속성 값을 static으로 설정하면 정의된 ID와 같은 html의 ID 값을 생성할 수 있습니다.기본적으로 이 값은 활성화되지 않으며 복잡하고 중첩된 ID 값이 생성됩니다.이것은 우리가 클라이언트에서 html 라벨을 조작하는 데 매우 어려운 것이다.
물론 당신이 MVC로 돌아갈 수 있는 이유는 아니지만, 그 이유 중 하나입니다. 비록 이 이유가 좀 억지스러울 수도 있습니다.
5. Leaky abstraction 취약한 추상html 모든 ClientIDMode 상태를 숨기려고 시도합니다 (http의 무기억성 또는 무상태성).서버 컨트롤을 드래그할 때 그가 언제 나타날지 고려해야 합니까?서버 컨트롤러가 이미 이러한 것을 실현했기 때문이다. 예를 들어 IsPostBack 방법은 왜 페이지가 다시 발송되는지 판단하는데 사용할 수 있습니까? 그 실현 원리는 무엇입니까?우리는 관심이 없다. 우리는 이 방법이 무엇을 완성할 수 있는지에만 관심이 있다. 이 정도면 충분한가?정말 충분해요?
나는 없다고 생각한다. 단지 사용할 줄 안다. 나는 영어를 아는 사람이라면 누구나 완성할 수 있다고 생각한다. 그러나 사용할 줄 알면 충분한가?성능 문제가 발생했습니까?어떤 문제가 발생합니까?우리는 모두 몰랐다. 우리는 단지 블랙박스를 썼을 뿐인데, 안에 무엇이 있는지 우리는 모른다.함정이라면 우리도 망설임 없이 뛰어들까?맞습니까?
가끔 원본 코드를 익히면 우리 자신의 개발 수준을 향상시키는 데 도움이 될 뿐만 아니라 우리가 통제할 수 있는 많은 문제점을 발견하여 그들이 발생하지 않도록 할 수 있다.그래서 사랑하는 여러분, 사용에만 국한되지 마세요. 때로는 큰 소와 송아지의 근본적인 차이는 송아지가 왜 이러는지 몰라요.소가 어떻게 더 잘 하는지 가르쳐줘요.
6.Low testability의 매우 낮은 테스트 성능
내가 이전에 개발Web form했을 때 서버 컨트롤러를 사용하면 개발 속도를 크게 높일 수 있었다.그러나 나는 내가 개발한 코드가 정상적으로 작동하는지 어떻게 테스트하는지 몰랐다.유일한 방법은 혼자 일이 없을 때 클릭, 클릭, 다시 클릭하는 것이다.그리고 인터럽트를 설정하고 F11을 누르고 키보드를 계속 눌러서 이 코드가 보일 때까지 토하고 싶을 정도?
그러나 MVC에서 이러한 문제는 더 이상 존재하지 않는다. 왜냐하면 우리는 Nunit 등 단원 테스트를 할 수 있는 도구를 사용할 수 있기 때문이다. 우리는 테스트를 줄마다 코드까지 정확하게 할 수 있고 테스트의 자동화를 실현할 수 있기 때문에 수동 클릭으로 낭비하는 많은 시간을 피할 수 있다.이것은 좋은 일이지, 그렇지 않니?
그리고 제가 개인적으로 가장 중요한 이유는 http의 개발 기반이 있다면 MVC를 배우는 것은 매우 간단한 일이라고 할 수 있습니다. 왜냐하면 MVC에 서버 컨트롤러가 없기 때문입니다. 어떤 것은 html 라벨과 html 라벨을 생성할 수 있는 helper류일 뿐입니다.저는 개인적으로 미용을 하는 사람이 개발을 하려면 좋은 시기라고 생각합니다. 왜냐하면 html은 미용사에게 펜 프로그래머가 더 익숙하기 때문입니다.
MVC에서 web form 없이 html을 완전히 제어할 수 있고 원래의 web form를 사용하지 않고 View State에서 자체적인 Url rewriter(Url 루트 시스템), 좋은 관심점 분리 프레임워크MVC를 사용할 수 있으며 각 층마다 자신의 임무를 맡는다.Route에서 모든 주소가 하나의 구체적인 페이지에 대한 것은 아니다. 여러 개（Model、View、Controller）를 정의하여 같은 페이지로 돌아갈 수 있다.MVC에서 강력한 루트 시스템이 있기 때문에 우리는 다시 볼 수 없다Action. 이런 주소가 아니라 대신MVC이다. 이것은 거대한 돌파이다.특정한 페이지를 구체적인 의미를 가지게 할 수 있다.이것은 URl의 우호적인 것 같은데, 당신은 어떻게 생각합니까?www.cnblogs.com/default.aspx가 www.cnblogs.com/home/index를 대체할 것이라고 말한 것이 아니라 그들 간의 대비성이다. 물론 일부 문제의 존재를 피할 수 있다면 MVC와 Web form가 같은 프로젝트에 모두 존재하는 것은 좋은 선택이 아닐 수도 있다.그러나 전제는 네가 MVC를 배워야 한다는 것이다. 나는 개인적으로 앞으로 몇 년 동안 웹 폼과 MVC가 공존할 것이라고 생각한다.
자, 이렇게 많이 말했는데 한마디만 할게요. 미래의 웹 개발에서 뒤처지지 않으려면 여가 시간에 MVC를 배워보세요.
만약 당신의 사이트가 더욱 좋은 유지보수성을 가지고 있다고 생각한다면, MVC를 채택하는 것은 당신의 현명한 행동이다.