telerik을 사용하고 있습니다.
View단 Behind Code는 지양해야 한다고 알고 있는데,
telerik radDatePicker 사용 시 보여주는 날짜 포맷은 2가지만 제공하고 있습니다.
현재, 요구사항에 따라 커스텀 해야하는 상황입니다.
찾아보니 telerik 매뉴얼에는 Behind Code로만 나와있는데요.
UI 라이브러리이기 때문에 View단에서만 해결 가능하다고 생각합니다만,
저의 궁금증은 이렇습니다.
ViewModel에서 View 요소에 직접 접근하는 것이 가능한지?
1-1. 만약 가능하더라도 MVVM 패턴 규칙을 해친다고 생각하는데 해치는 것이 맞는지?
라이브러리가 강제할 경우 라이브러리 규칙을 따를 수 밖에 없는지?(Behind Code 작성)
먼저 답을 드리고, Behind Code에 대해 설명 드리겠습니다.
가능합니다.
1-1. 하지만 직접 접근하면 안됩니다. ViewModel에서 View의 의존성이 생기기 때문이며 MVVM 디자인을 해칩니다. 필요한 View 동작 인터페이스를 만드시고 View에서 인터페이스를 구현한 다음 그 인터페이스를 ViewModel에서 사용하시면 됩니다.
따르는게 좋습니다. 이유는 아래에…
먼저 View에서 View에 관련된 Behind Code를 작성하는 것은 MVVM 디자인을 해치는게 아닙니다. View의 영역은 보이는 XAML 및 보이는것과 관련된 Behind Code를 포함합니다.
결론은 View단에서 View와 관련된 Behind Code를 지양할 필요가 없습니다.
라이브러리를 사용하고 있기 때문에 굳이 인터페이스를 만들어서 해결할 필요는 없겠군요.
패턴 정의를 다시 찾아봤으면 금방 이해할 수 있는 내용이었던 것 같습니다.
명료한 답변 감사합니다.
제가 경험한 WPF UI 서드파티 라이브러리들은 대부분 매뉴얼 코드가 비하인드로 작성되어 있었습니다.
그렇다고 코드를 보면 반드시 비하인드 코드에서만 작성할 수 있는 것은 아닌데요, 그럼에도 왜 비하인드 코드로 매뉴얼을 작성하냐면 단지 그 기능을 소개하고 사용하는데 중점을 두었기 때문입니다.
그러니 사용자 입장에서는 XAML쪽과 비하인드 코드 양쪽을 모두 같이 보고 나에게 가장 적절한 형태로 재구성을 해야 합니다.
안그러면 MVVM을 해칠 가능성이 매우 높고 굳이 이게 아니더라도 코드 읽기가 매우 어려워집니다.
이에 제 생각에 2의 경우 라이브러리가 강제하는 것이 아니라 이런 기능이 있다는 것을 알려줄 뿐이고 사용자는 그 기능을 확인한 다음 @dimohy 님 말씀처럼 적절하게 재구성하여 사용하는 것이지 않을까 합니다.
재구성은 어떤 방식을 통해 가능한가요?
라이브러리를 재구성 해서 사용하는 것이 라이브러리를 사용하는 의미를 퇴색하는 것은 아닌지 궁금합니다.
1. 재구성 방식
지금 당장 생각나는 건 원하는 동작을 behavior로 만들거나, 해당 control 클래스를 상속받아 원하는 기능을 mvvm 친화적으로 노출할 수 있는 custom control을 만들거나, 라이브러리가 오픈 소스인 경우 코드를 직접 수정한다거나 하는 방법이 있을 것 같네요.
모두 각자만의 방식이 있을 것이기 때문에 이 부분은 이용자님께서 직접 해보시면서 본인에게 익숙하고 편한 것을 선택하시면 될 것 같습니다.
2. 라이브러리를 재구성해 사용하는 게 라이브러리를 사용하는 의미를 퇴색시키는가
강하게 부정합니다.
오픈 소스인지 클로즈드 소스인지, 유료인지 무료인지에 상관없이 라이브러리가 오롯이 원본 그대로 사용되기만을 바라는 사람이 누가 있을까 싶네요. 라이브러리를 제작자가 목표하는 환경과 실제 사용자가 사용하는 환경은 대체로 차이가 있을 수밖에 없기 때문에, 필연적으로 크게든 작게든 사용자의 수정을 거칠 수밖에 없습니다.
시야가 좁다보니 제한적으로 느꼈나봅니다.
이번 기회에 실력을 좀 키울 수 있을 것 같습니다.
원하는 것이 동작이 아니라면 Custom Control을 만드는 것이 맞을까요?
포맷만 변경하면 되는 거라 굉장히 간단할 것 같은데 Custom 해본 적이 없어서 막연하기만 합니다.
방향이 맞다면 연구해보겠습니다.
어느 쪽이든 UI쪽 로직을 View에 작성하고, 비즈니스 로직과 관련된 부분을 Model이나 ViewModel에서 사용할 수 있도록 적절하게 노출하도록 하는 것이 목적이기 때문에 이를 지키면서 구현한다면 큰 차이는 없을 겁니다. 이를 지킨다면 사실 프리젠테이션 로직은 코드 비하인드에 작성하든, behavior로 분리하든, 상속해서 custom control을 만들든 상관은 없습니다.
또한 제시한 대로 라이브러리를 수정하는 방법은, 재사용하는 것이 주 목적이 된다고 생각합니다. 나중에 유사한 컨트롤을 사용할 필요가 있을 때 이미 만들어둔 걸 갖다 쓰기만 하면 되니까요. 재사용 목적이 아니라면, 컨트롤의 코드 비하인드에 작성하는 게 난이도나 소요 시간 면에서 이점이 클 듯합니다. 윗 문단에서 서술한대로 프리젠테이션 로직은 View에 작성하고, 비즈니스 로직은 Model이나 ViewModel에 작성한다는 원칙만 지킨다면 됩니다.
이번 작업은 코드 비하인드에 진행해도 괜찮겠다는 판단이 서네요.
다른 방법들은 연습삼아 만들어봐야겠네요.
진심으로 감사드립니다.