2012-05-18 9 views
1

.Net에서 웹 개발 세계를 볼 수 있습니다. 이제 Asp.Net Webforms와 MVC로 나뉘며 동일한 응용 프로그램에서 둘 다 사용하는 것을 선호하는 세 번째 범주가 있습니다.Asp.Net 응용 프로그램 성능

내 질문 : ViewState는 대다수의 응용 프로그램에서 악의적 인 것으로 간주되어 성능 병목 현상이 많이 발생합니다. 그러나 우리가 그것을 정확하게 사용하면 전혀 문제가 없습니다. Asp.Net MVC 3.0/4.0 베타 주위에 너무 많은 윙윙 거리며 ViewState가없는 것입니다. 내가보기 나의 관심사는 그러나

, 어떻게 Asp.Net MVC 도움이 속도를 최대 성능 때문에 우리는

if (!IsPostback) {} 
Asp.Net MVC에서 우리는 각각의 제어 및 모든 시간을 결합

과의 컨트롤을 바인딩 할 수 있습니다 양식이 게시 될 때마다 데이터베이스를 요청할 수 있습니다. Asp.Net Winforms는이 점에서 우위에 있지 않습니까? Asp.Net MVC가 모든 경우에 더 나은 성능을 발휘할 것이라는 점을 보장 할 수 있습니까?

편집 : 내가 어떤 논쟁을 시작하지 않으 및 추가 I는 자바 스크립트 축소를, CSS의 축소를 다른 모든 트릭 후 성능에 대해하지 Asp.Net 코드에 대해 이야기하고있다.

+3

아마도 당신은 이것을보고 싶습니다 : http://stackoverflow.com/questions/43743/asp-net-mvc-performance – Falaque

+0

당신은 절대적인 보증을 요구하고 있으므로 "아니오, 그렇지 않습니다. 보증." 그 대답에 매우 편안함을 느낍니다. 들어가기에는 너무 많은 요소가 있지만 내 경험에 따르면, 일반적으로 동일한 페이지에 대해 더 가볍고 빠른 느낌을줍니다. localhost가 아닌 연결에 대해 ViewState를 전송하는 네트워크의 성능이 있다는 것을 잊지 마십시오. 브라우저는 DOM에서이를 처리해야합니다. 모든 성능 항목이 ASP.NET 파이프 라인에있는 것은 아닙니다. –

+1

아니요. 많은 웹 응용 프로그램 성능 요인이 있습니다. WebForms처럼 쉽지는 않지만 끔찍한 MVC 코드를 작성할 수도 있지만 여전히 가능합니다. 무엇보다, 웹 애플리케이션 파이프 라인과 성능 병목 현상 (모든 프레임 워크에 관계없이)을 잘 이해하는 것이 중요합니다. – jrummell

답변

1

훌륭한 대답은 모두 들지만 2 센트도 던질 것입니다.

if (!IsPostBack)으로 컨트롤을 바인딩하면 암호화 된 viewstate 필드가 webforms 페이지에 쓰여집니다. 다음 요청 동안 모든 상태가 서버에 전송되고 해독/역 직렬화됩니다. 페이지에 GridView가 있으면 모든 행이 viewstate에 있으므로 다시 데이터 바인딩을 위해 다른 db 요청을하지 않아도됩니다. 서버에 이런 의미에서

, 그것은 메이크업 성능 개선 . 그러나 여기에 언급 된 다른 사람들이 말했듯이, 당신은 모든 viewstate를 서버에 보내는 네트워크 공격을받습니다. 또한 상태를 뒤로 밀어야합니다. 잠재적 인 viewstate 악용을 극복하고 웹 폼의 성능을 향상시키기 위해 viewstate를 의도적으로 유지하는 것처럼 들립니다. viewstate가 종종 남용되거나 심지어 무시되기 때문에 이는 확실히 좋은 습관입니다.

페이지가 매겨진 GridView를 클라이언트로 푸시 다운하는 예제를 고려하십시오. GV에 15 개의 행이 포함되어있는 경우 클라이언트에 모든 것을 푸시하고 백업시 직렬화를 해제하고 첫 번째로드 이후에 DB를 치지 않으면 성능이 향상 될 수 있습니다. GV에 1500 개의 행이 포함되어 있지만 최종 사용자는 viewstate에서 전송하지 않고 각 페이지 매김 요청 중에 db를 방문하면 성능이 향상됩니다. 그러나 GV에서 세부 정보 페이지로 연결되는 즉시 "뒤로"버튼을 클릭하면 데이터를 다시 게시하라는 메시지가 표시됩니다.이 행의 수와 관계없이 항상 귀찮습니다.

궁극적으로 웹 폼 페이지를 제공하고 소비하는 시스템에서 개발할 때 성능이 향상 될 수 있습니다. 하지만 viewstate의 크기에 따라 네트워크를 통해 콘텐츠에 액세스하는 사람들이 당신처럼 속도의 종류를 보지 못할 수도 있습니다. It all depends on how fat your viewstate is.

MVC 팬들이 많이있는 이유 중 하나는 only need to send the minimal request to the server that is needed to perform a specific action입니다. 페이지의 모든 웹 컨트롤에 대해 모든 데이터 & 상태를 제출하는 단일 모 놀리 식 양식 대신 모든 양식을 분리하고 대신 전체 양식을 비 직렬화하는 대신 다른 작업으로 섹션이나 청크를 보낼 수 있습니다.

다른 사람들이 말했듯이 질문에 대한 간단한 대답은 '아니오'입니다. MVC는 웹 폼보다 항상 빠르거나 성능이 좋은 것은 아닙니다. 흑백이 없습니다. 많은 경우에 할 수 있고 할 수 있지만, 또 다른 사람들이 말한 것처럼, some apps are better suited for webforms. 또한, 당신의 유일한 관심사는 성능입니까? MVC는 성능이 항상 "의존"할지라도 다른 영역의 웹폼보다 검은 색 &의 장점을 가지고 있습니다.

+0

나는 당신의 대답이 가장 마음에 들었다. 그러나 나는 1500 행을 클라이언트에 밀지 않을 것이다 :). 최대 나는 서버 50 행 최대 7 열을 갖는 :). Btw, 그것은 암호화되어 있지 않습니다 (Base64). – Jack

+0

좋습니다,하지만 원래의 질문에는 언급하지 않았습니다.저는 왜 MVC가 웹폼보다 "윙윙 거리는 소리"가 나는지 설명하고 어떤 경우에는 더 잘 수행 할 수있는 방법을 설명하려고했습니다. – danludwig

+0

MVC와 관련하여 다른 보안 질문이 있습니다. 아마도 다른 질문에 게시 할 것입니다. 오늘은 6 쿼터/쿼터의 쿼터가 이미 끝났습니다. :) – Jack

0

가벼운 내용을 표시해야하는 사이트에 MVC가 더 적합하다고 개인적으로 생각합니다. 그러나 하루 거래자를위한 그리드를 작성해야하는 경우 Web Forms가 유리합니다.

ASP.net MVC는 asp.net 웹 양식과 달리 컨트롤을 바인딩하지 않습니다.

이렇게하려면 JQuery를 사용해야합니다. Jquery는 뛰어난 성능을 제공합니다. MVC \의 JQuery와 전문 지식의 훨씬 더 높은 수준을 요구하는

http://www.codeproject.com/Articles/305308/MVC-Techniques-with-JQuery-JSON-Knockout-and-Cshar

또한

그것은 중요한 언급. 비용면에서 결론을 지켜야합니다. 비용은 일반적으로 프로그래머가 무시하지만 모든 프로젝트에서 중요한 역할을합니다.

2

MVC의 장점은 성능이라고 말할 수는 없겠지만 아마 더 빠를 것이라고 생각합니다. 장점은 컨트롤의 winforms 같은 라이프 사이클을 다루지 않는 것입니다. 한 페이지에 더 많은 것이 있으면 개발이 더 복잡해지지 않을 것입니다. 단 한 페이지에서는 컨트롤을 통해 라이프 사이클 이벤트가 올바르게 수행되지 않으면 서로의 단계를 밟을 수 있습니다.

성능과 관련하여 MVC의 수명주기는 정적입니다. 몇 가지 사건이 발생하지만 그 정도의 변화는 없습니다. 실적 문제는 귀하의 행동 방식에 있습니다. 웹 양식을 사용하면 컨트롤이 사용되지 않거나 표시되지 않는 경우에도 모든 이벤트가 다시 게시 될 때마다 여러 이벤트 및 컨트롤 레크리에이션이 발생합니다. 웹폼에는 훨씬 더 많은 낭비가 있습니다. MVC는 성능이 좋고 개방적인면이 대조적입니다.

2

mvc (MS 또는 다른 프레임 워크가 될 수 있음)는 웹의 상태 비 저장 속성 및 개념과 더 유사합니다.

webforms는 웹 개발이 안정적인 데스크톱 클라이언트처럼 작동하도록 설계되었습니다. 이것이 페이지 이벤트, 포스트 백 및 뷰 스테이트가 존재하는 이유입니다.

저는 50MB의 viewstate를 보았습니다. 이것은 확실히 성능을 해친다. mvc 프레임 워크를 사용하면 페이지 크기를 오히려 빨리 줄일 수 있습니다. 그러나 mvc의 장점은 1. 단순함 (webforms 페이지 수명주기와 비교)과 2. 확장 성입니다.

컨트롤러 팩터 리, 유효성 검사 또는 뷰 엔진의 기본 구현이 마음에 들지 않으면 mvc에서 스왑 할 수 있습니다.webforms와 함께 할 수 없습니다.