2010-01-06 3 views
4

좋아요, 저는 비즈니스 논리 결정을 내리는 것이 아니라 UI 결정에 대해 말하고 있습니다.ASP.NET MVC : 내보기가 얼마나 어리석은가요?

예를 들어 테이블을 렌더링하고 하나의 열에 DateTime이 표시됩니까? 형식을 지정해야하는 속성 값이 nullable이기 때문에 서식 지정 전에 null이 아닌지 확인해야합니다. 나는 학자가되고 싶었 경우

, 내 뷰 모델에 FormattedDate 속성을했을 :

public class MyViewModel 
{ 
    ... 
    public DateTime? Date { get; set; } 

    public string FormattedDate 
    { 
     get 
     { 
      return this.Date.HasValue ? this.Date.Value.ToShortDateString() : ""; 
     } 
    } 
} 

<%= Html.Encode(Model.FormattedDate) %> 

아니면 내가 나 자신에게 몇 줄의 코드를 저장하고 간단히보기에서 때릴 수 :

<%= Html.Encode(Model.Date.HasValue ? Model.Date.Value.ToShortDateString() : "")%> 

이 경우 뷰에 영향을주는 것이므로 두 번째 방법 (그리고 더 컴팩트)을 수행하는 것이 좋을 것이라고 주장하지만, 뷰가 서버와 어수선하게 얽히면서 사이드 코드와 내 ViewModel에 "서식 지정"속성이 어수선하게 남겨져 있습니까? 당신이 많은 것을 할 뭔가 경우

답변

4

뷰에 직접 입력하면 관련 코드 줄이 실제로 저장되지 않습니다. 단지 주위를 이동하기 만합니다.

그러나보기에 넣으면 그 위치에서만 사용할 수 있습니다. 다른 곳에서 ViewModel의 로직을 재사용 할 수는 없으며 단위 테스트를 할 수 없습니다.

조회수가 너무 낮습니다. Views는 가능한 한 낮은 Cyclomatic Complexity이어야합니다.

자세한 내용은 this answer을 참조하십시오.

+0

보기가보기에 논리가 있어야하는지 여부에 대한 질문이 정착된다. 로직이 어디로 가야하는지에 관해서는 David M이 제안한 포맷 확장 메소드를 사용하는쪽으로 기울어 져 있습니다. 로직을 테스트 가능하고 특정 ViewModel에서 분리 해줍니다 (당연히 다른 시나리오를 볼 수 있습니다. 더 많은 도메인 개체는 날짜 형식을 지정하는 것보다 특정하므로 ViewModel 자체에 있어야합니다.) –

+1

확장 메서드를 테스트 할 수는 있지만 View는 올바르지 않은 것으로 확인되는 단위 테스트가 없습니다. 보기에서. 확장 메서드에서 View의 일부를 구현하고 ViewModel에서 일부를 구현하여 Cohesion의 원칙을 깨뜨리는 것이 좋을 것 같습니다. ViewModel에 모든 것을 넣으면 Single Responsibility Principle을 따르는 동안보다 높은 응집도를 얻을 수 있습니다. –

1

은, 아마 당신은과 같이 Nullable<DateTime>에 대한 확장 메서드를 작성할 수

static public string Format(this DateTime? value) 
{ 
    return value.HasValue ? value.ToShortDateString() : string.Empty; 
} 

는 뷰 모델 또는보기의 혼란을 저장합니다.

+0

그래, 내 경우에는 약간의 잔인한 일이지만 나중에 참조 할 때 염두에 두어야 할 것이다. –