프리젠 테이션 로직 대 UI 로직

Question

누구나이 용어를 명확히 할 수 있습니까?
나는 그것들이 매우 모호하거나 문맥 의존적이라는 것을 알았다.

예를 들어 항목 목록이있는 VM이 ​​있습니다. 이 선택은 버튼의 액세스 가능성 (즉, 명령이 실행될 수있을뿐만 아니라)뿐만 아니라 VM의 동작에도 영향을줍니다. 즉, 여러 항목이 동시에 편집해야하는 경우가 있습니다.

두 번째 예는 새 항목을 만드는 과정입니다.
사용자가 제공 한 데이터를 사용하여 항목을 항목 모음에 추가하여 목록에 삽입하고 선택한 항목에 집중하려고합니다. 이제 항목의 VM에 대해 IsSelected 및 IsFocused 속성을 도입하여이 작업을 수행합니다. 실제 작업은 바인딩, 연결된 속성 및 동작을 통해 뷰에서 수행됩니다. VM에 속성 같은 종류 (IsVisible, IsSelected, IsFocused 등)을 추가하는 우리 팀의 insits의

일부 회원들은 VM에 UI 로직을 제공하고 UI 및 프리젠 테이션 로직이 혼합되어 있기 때문에 그건 좋은 방법이 아닙니다.

다음 패턴은 importand이지만 나 자신을 반복하지 않는 것이 더 중요합니다. DataContext를 구체적인 VM의 유형에 캐스팅하지 않고 코드 비헤이비어에서 바인딩 및 몇 줄을 선호하며 VM의 메서드를 호출하는 등의 작업을 선호합니다.

그럼에도 불구하고 나는 HolyWars를 좋아하지 않으며,이 두 용어에 대한 오해와 다른 하나의 분리 기준 때문에 잘못 될 수 있음을 인정합니다.

Answer 1

프리젠 테이션 로직을 VM에 넣고 IsEnabled와 같은 속성을 사용하여 테스트 할 수있게하는 것이 중요하다고 생각합니다. 또한 뷰의 복잡성을 줄여서 단위 테스트 할 수없는 코드의 양을 줄입니다.

또한 동료의 경우 VM의 프리젠 테이션 논리가 모범 사례가 아닌 이유에 대해 언급하고 싶습니다. IMHO는 프리젠 테이션 레이어의 일부이며 VM의 목적은 뷰를 모델링하는 것입니다. 따라서 프리젠 테이션 로직을 여기에 넣는 것이 자연스러운 것처럼 보입니다.

추가 편집 :

뷰의 책임

Implementing the MVVM Pattern에서 사용자가 화면에서 보는 것을의 구조와 모양을 정의하는 것입니다. 이상적으로는 뷰의 코드 숨김에는 InitializeComponent 메서드를 호출하는 생성자 만 포함됩니다. 경우에 따라 코드 숨김에는 복잡한 애니메이션과 같이 XAML (Extensible Application Markup Language)로 표현하기가 어렵거나 비효율적 인 시각적 동작을 구현하는 UI 논리 코드가 포함되어 있거나 코드에서 시각적 요소를 직접 조작해야하는 경우가 있습니다 보기의 일부. 단위 테스트에 필요한 논리 코드를 뷰에두면 안됩니다. 일반적으로보기의 코드 숨김에있는 논리 코드는 UI 자동화 테스트 방법을 통해 테스트됩니다.