2011-01-06 5 views
5

샘플 MVC 코드에서 볼 수있는 거의 모든 컨트롤러 메소드가 ActionResult를 반환하는 이유는 궁금합니다. 코드가 한 유형의 결과 만 반환 할 수 있다고하더라도 분명합니다. 논리에 따라 RedirectResult 나 ViewResult를 반환 할 수도 있기 때문에 보증할만한 사례가 있음을 알고 있습니다. 그러나 그 방법은 제가 본 대부분의 경우에는 해당하지 않습니다.대부분의 MVC 샘플 컨트롤러 코드가 ActionResult를 반환하는 이유는 무엇입니까?

메쏘드에 'object'의 리턴 타입을 갖는 것이 그다지 다르지 않습니까? 반환 형식으로 JsonResult, FileResult 또는 ViewResult를 지정하지 않는 이유는 무엇입니까? 모든 컨트롤러 메소드에서 ActionResult에 반환 유형을 설정하지 않는 것이 이점이 있습니까?

클래식 예 :

public ViewResult Index() 
{ 
    return View(); 
} 

편집 :

public ActionResult Index() 
{ 
    return View(); 
} 

왜이 대신의 규범 것으로 보인다 지금까지 모든 일을 제외하고는 답변은 지적했다 ActionResult 좀 더 일반적인 것입니다. 나는 그 정도를 압니다. :) 컨트롤러 메소드에서 왜 이것이 받아 들여지 는가? 일반 메소드에서 수행 할 수있는 유형의 최상위 레벨 클래스를 반환하는 것이 아니라 일반적으로 가장 구체적인 유형을 리턴하려고 시도합니다. 컨트롤러 메소드가 블로거와 "샘플 코드 작성자"(예, 나는이 용어를 만들었습니다)가 ActionResult를 반환하는 데 너무 의존하게 만드는 이유는 무엇입니까?

+0

가능한 복제 [ASP.NET MVC 컨트롤러 메서드 반환 ActionResult?] (http://stackoverflow.com/questions/1021568/must-asp-net-mvc-controller-methods-return-actionresult) – bzlm

답변

6

여기에 허용 된 대답에서 인용 한 varbatim입니다. 나에게 의미가 있습니다 : 당신은 절대적으로 대부분의 예는 웹이 ActionResult를 반환하는 것, 비록 특정 반환 유형을 사용할 수 있습니다

Must ASP.NET MVC Controller Methods Return ActionResult?

. 유일한 시간은 내가 ActionResult 클래스를 반환 할 때 동작 경로가 다른 경로 은 다른 하위 유형을 반환합니다.

스티븐 샌더슨은 는 그의 책 Pro ASP.NET MVC Framework의 특정 유형을 반환하는 것이 좋습니다. 아래의 인용문을 살펴 보자.

"이 작업 방법은 특별히 이 인스턴스 ViewResult의 을 반환 선언을 그것은 단지 같은 대신 메소드의 리턴 타입 이 ActionResult를 인 경우 (기본 클래스를 작동합니다 모든 행동의 결과)에 대한. 사실, 어떤 ASP.NET MVC 프로그래머들이 확실히 알 경우에도 비특이적 ActionResult를 반환하는 모든 자신의 액션 메소드를 선언 그것이 그러나 항상 복귀 하나 개의 특정 서브 클래스입니다. 것이다, 그것은 잘 설립 된 0123입니다.원칙적으로 객체 지향 의 메소드는 메소드가 을 반환해야한다고 프로그래밍합니다 ( 은 대부분 매개 변수 유형을 수용 할 수 있음). 다음에이 원칙은 편의를 극대화하고 단위 테스트와 같은 방법으로 을 호출하는 코드에 유연성을 제공합니다. "

도 참조 :

http://www.bengtbe.com/blog/post/2009/07/01/Use-specific-return-types-in-your-ASPNET-MVC-action-methods.aspx

+0

나에게도 의미가 있으며 대답으로 받아 들일 것이지만 여전히 왜 그런지 궁금합니다. 환경에서 가능한 한 구체적으로 리턴 타입을 선언하는 데 익숙한 개발자라면 갑작스런 MVC 프로그래머가 특정 상황에서 그 개념을 버린 것처럼 보입니다. 전혀 의미가 없습니다. – Scott

+2

@Scott Schluer : 컨트롤러 동작에 대한 실제 "소비 코드"는 일반적으로 브라우저 또는 자바 스크립트이므로 형식 안전성의 이점은이 특정 인스턴스에서는 덜 두드러집니다. GWT의 RPC 프레임 워크가 설정된 방식으로이 코드를 유형 안전 언어로 사용할 수 있다면 사람들은 특정 반환 유형을 설정하는 것에 대해 더 신중할 것입니다. – StriplingWarrior

+2

나는 ActionResult를 사용하는 것이 꽤 편리하다는 것을 발견했다. 나는이 특정 상황에서 감소 된 타입 안전성 문제가 더 좋아지게됨에 동의한다. 저는 이것이 편의와 가독성을 위해 주로 파생 된 방법이라고 생각합니다. ActionReult를 볼 때, 나는 그 방법의 목적이 바로 무엇인지를 안다. 그리고 그 액션에 리다이렉트를 던질 필요가 있다면 그렇게하기 위해 리턴 타입을 수정할 필요가 없습니다. – Derrick

0

반환 유형이 컨트롤러 내부 로직의 b/c가 될지 확실하지 않은 경우에만 일반 반환 유형을 사용해야합니다. 그렇지 않으면 - 특정을 사용하십시오 (BETTER 프로그래밍으로 간주됩니다).

명 샘플에서 ActionResult를 사용하는 이유 나도 몰라,하지만 난 동의하지 않을 수도 샘플에서 많은 일을 본 적이 - 무슨 소용이 걸릴 거기에 나머지를 떠나 ....

IMHO - 당신은 이것이 당신이 사용하는 리턴 된 유일한 객체이고, ActionResults가 아니라는 것을 알고있을 때 ViewResult를 사용해야합니다.

1

내 생각에 코드를 좀 더 구체적으로 만들 필요가 없으므로 더 구체적인 결과가 아닌 ActionResult이 반환됩니다.

보다 일반적인 유형을 사용하면 작업을보다 유연하게 유지할 수 있습니다.

반환 유형을 변경하면 웹 응용 프로그램 프로젝트에서 문제가되지 않을 수도 있지만 테스트 프로젝트의 모든 단위 테스트도 변경하게됩니다.

+0

것 같습니다 나에게 당신이 돌아 오는 것을 바꾸면, 어쨌든 그 변화를 반영하기 위해 단위 테스트를 변경해야 할 것입니다. 컴파일러에게 "이 단위 테스트는 더 이상 작동하지 않습니다"라고 말하면됩니다. 대부분의 경우, 단위 테스트는 반환 된 ViewResult의 Model이 예상 한 값과 같은지를 테스트하기 위해 결과를 실제 유형으로 캐스팅해야합니다. – StriplingWarrior

+0

@ StriplingWarrior - 필자는 개인적으로 프로젝트를 구축하고 단위 테스트에서 부서진 코드로 인해 프로젝트의 빌드를 보류하는 대신 내 단위 테스트가 실패하는 것을 알 수있었습니다. –

+0

나는 그것이 의견의 문제라고 생각한다. 나는 개인적으로 컴파일 시간에 더 많은 이슈를 잡는 것이 시간을 절약 해 주며, 타입 안전하고 컴파일 된 언어를 사용하는 가장 큰 이유 중 하나라고 생각한다. – StriplingWarrior

0

ActionResult가보기에서 처리 할 수있는 가장 높은 개체이기 때문일 수 있습니다. 나를 위해 ViewResult

System.Object 
    System.Web.Mvc.ActionResult 
    System.Web.Mvc.ViewResultBase 
     System.Web.Mvc.ViewResult 

ActionResult

, 각 XXXResult은 특정 사용하기 위해 최선을 다하고 있습니다. 특정 작업이 필요하지 않은 경우 ...

0

MVC 템플릿의 자동 생성 코드가 ActionResult로 시작하고 사람들이 패턴을 따라 간다고 생각합니다. 많은 사람들이 자신의 컨트롤러 동작을 단위 테스트하지 않기 때문에 결과를 유형 안전 방식으로 소비하지 않으므로 문제가 될 수 있습니다.

+0

그건 이상한 것처럼 보입니다. http://weblogs.asp.net/scottgu/archive/2010/07/27/introducing-asp-net-mvc-3-preview-1.aspx를 확인하십시오. Scott Guthrie조차도 그 일을하고 있으며, 그는 그가 이해 부족으로 인해 나오는 것을 따라 다니는 개발자가 아니라고 확신합니다. :)보기 만 반환하는 간단한 컨트롤러 메서드입니다. 반환 형식은 ActionResult입니다. – Scott

0

ScottGu는이 같은 이유로 4 prob는 않았다, 그것은 예를 보여 그냥 쉽게 데모의 주제는 자주 볼 수있는 송시 품질을 지시;. 예를 들어 방금 전의 경우, 그들은 일반적으로 요점을 설명하기 위해 무언가를 던져 버릴 것입니다. (그들은 최종 b4 게시에 예제를 작성/테스트하는 것을 쉽게했고, 게시 할 때 그대로 남겨 두었습니다.) HTML과 JS (본질적으로)에 대해 "신경 쓰지 않는"유형에 관해서는 JavaScrip t (약점 유형과 같음) 누수를 통해 누출되거나 자신 만의 좋은 코딩 스타일을 감염시킵니다. 가능하면 특정 유형을 사용하십시오. 게다가, ur JS 코드는 어쨌든 JSON 결과를 기대할 수 있습니다 (입력 우수 사례를 사용하여 코딩 된 경우). 코드도 테스트 할 수 있다고 생각하고 있으므로 시도 할 경우 JS 코드의 손을 묶고 싶지는 않습니다. 할 수있는 유형에 맞는 일을하는 것. 어떤 경우에는 부작용이 다른 것보다 (덜 안전한 타입의 언어로 되돌아가는 것과 같이) 더 많거나 적다는 것이 맞습니다. 일관성있는 프로그래밍 습관 일뿐입니다. 일반적으로, 이런 종류의 일을하면 결과적으로 사용하고자하는 특정 객체의 기능으로 되돌아 가도록 일종의 유형 변환/조정이 수행됩니다 (기본 객체에서는 사용할 수 없을 가능성이 더 높습니다. 항상 그렇다, 당신의 유형은 너무 구체적/어쨌든 기지가되어야한다). 주조는 본질적으로 추악하고/악합니다. 런타임에 타입을 파생하면 문제가 생길 수 있습니다 (왜 실습이 낙담적인지/정적/강력한 타이핑/안전성을 가진 사람들은 수십 년 동안 칭찬을 받았습니까). 코드의 소비자/관리자가 metainfo를 통해 식별 할 수있게합니다 (메소드를 가리키면 됨).) 함수가 실제로하고/리턴하고있는 것. 실제로 단위 테스트에서는 테스트 할 수있는 조건이므로 Steven Sanderson의 책에서 발췌 한 내용을 참조하십시오. 그리고 나는 약하게 입력 된 이유로 빌드를 갖고 싶지 않은 사람을 잡았습니까? 정말?

관련 문제