나는 내가하고있는 일이 패턴을 따르고 모범 사례이거나, 누군가 구두로 나를 제출하여 남용한다는 확인/검증을 찾고 있습니다!Do not do. MVVM의 Valueconverters
[여기에 컨트롤 삽입]에서 가시성 바인딩을 수행하는 경우이를 System.Windows.Visibility 유형의 속성에 바인딩합니다. 비즈니스 로직에 따라이 값을 Visible/Collapsed로 설정합니다. 이것의 한 가지 잠재적 인 결함은 내 VM 속성이 이제 내가 값 변환기로 추상화되는 것을 볼 수있는 유형에 직접 연결되어 있다는 것입니다. 그 말로는 MVV 토론에서 ValueConverters를 사용해서는 안된다는 것을 종종 읽었습니다.
이 의견에 대한 의견을 얻을 수 있습니까?
감사합니다.
SS
나는 변환기가 팬이지만 특히 재사용 할 수 있습니다. ViewModel에서 이러한 변환을 쉽게 수행 할 수 있지만 많은 ViewModel 또는 15 가지 응용 프로그램에서 동일한 변환을 원한다면 어떻게해야할까요? ViewModel 접근 방식으로 제한한다면 DRY를 위반하게됩니다. 즉, 나는 비즈니스 로직을 포함해서는 안되며 "일회성"솔루션에 사용해서는 안된다는 것에 더 동의하지 않는다.
위에서 언급 한 경우 ViewModel에 Visibility 유형의 속성이 필요합니다.이 속성은 나에게 코드 냄새입니다. IMHO, ViewModels는 시각적 상태를 반영해서는 안되며, View의 Visual 상태가 ViewModel의 데이터 상태에 반응해야합니다.
그것은 논쟁의 주제이다하지만 난 당신이 컨버터를 사용하지해야한다고 생각 어디 캠프에 앉아있다. ViewModel은 "변환기가 스테로이드"로 간주되므로 변환기가 필요하지 않습니다. (http://groups.google.com/group/wpf-disciples/browse_thread/thread/3fe270cd107f184f?pli=1)
당신이 컨버터를 사용하는 경우, 당신은 그들이에 대한 프로젝트의 모든 곳에서 끝날 것을 찾을 수 있습니다 가장 평범한 것. 예 : '3 고객'을 표시하고 '1 고객'인 경우 복수를 원하지 않습니다. 뷰 모델에서는 쉽게 수행 할 수 있지만 변환기에서는 실제 작업을 지루하게 진행합니다.
일반적인 UI 시나리오 (예 : 부울 속성에 대한 가시성 바인딩)에 값 변환기를 사용하는 것이 좋다고 생각합니다. 그러나 UI와 관련된 작업에만 사용해야합니다. 비즈니스 논리를 변환기에 넣지 말고 거기에 속하지 않습니다.
보기 (XAML/WPF) 및 ViewModel은 다른 작업을 담당합니다. 따라서 ViewModel이 제공하는 데이터를 조작하는 경우 ViewModel에서 변환하는 것이 가장 좋습니다. 그러나 순전히 UI 요소에 대한 변환이 필요한 경우보기가 가장 적합합니다.
E.G. 나는 가시성이 ViewModel의 책임이라고 말할 것입니다. 아마도 표시되는 것을 둘러싼 비즈니스 규칙이있을 수 있기 때문입니다. 그러나 레이블을 변경하는 경우 복수 성은 아마도 UI 책임이어야합니다. 게다가 변환기가 아닌 트리거를 사용하기로 결정할 수도 있습니다. 이것은 ViewModel에 대한 문제가 아니어야합니다.
특정 패턴이 사용 중이기 때문에 무언가를 사용하면 안된다고 저는 생각하지 않습니다. 적용시기 및 코드를 테스트 가능하고 유지 보수 가능하게 만들고 품질 응용 프로그램을 제공하면서 쉽게 이해할 수 있는지 판단해야합니다.
"VM 접근 방식으로 제한하면 DRY를 위반하게됩니다."- ftw. 감사! –