1. 비슷비슷한 커맨드들이 약간씩 바뀌어서 중복되는데, 보통 어떤 방법으로 줄일 수 있는지?
public ICommand DoCommand1;
private void DoWork1(object parameter)
{
if ( parameter is A a )
{
a.DoSomething1();
…
}
}
public ICommand DoCommand2;
private void DoWork2(object parameter)
{
if ( parameter is A a )
{
a.DoSomething2();
…
}
}
뭔가 애매함
내가 잘 하고 있는건지는 모르겠고 보통 저 object parameter 매개변수로 컨트롤 보내주게 되던데
동일한 컨트롤을 보내주면서 메소드만 다르게 쓰이는 케이스가 꽤 되어서
패턴들 적용하다보면 구조가 더 복잡해질거같음..
2. Interaction 태그와 이벤트 트리거를 굉장히 많이 쓰고 있는데, behavior의 개념을 보니까 특정 동작이 끝난 후 추가 동작을 덧붙이는 개념이 맞음? 많이 사용됨?
3. 유저컨트롤 내부의 데이터컨텍스트 등을 훅 해오는 편리한 방법이 있음?
재사용할거라고 막 만들다보니 유저컨트롤 안에 또 유저컨트롤이 있고.. 이런 구조가 되었는데, 내부 데이터에 접근하기가 너무 어려워서 코드비하인드에서 작업을 피할 수 없는 경우가 생겨버림
의존성 패러미터랑 이벤트핸들러 결국 다 쓰게 됨
4. 스택오버플로 뒤지다보니 어떤 외국인이 유저컨트롤은 코드비하인드에서 작업해야 편하다고 하는데, 개소리임?
1번은 사실 너무 추상적이라 뭐라 하기 어렵네.. parameter를 전달받는거야 ICommand가 그런거니 어쩔 수 없는데 command는 parameter를 안가지는게 더 좋은 디자인(처음부터 완결시켜놓고 null넣어 실행하면 바로 실행되게 하는거)이라고 봄
나도 이론상으로는 뷰모델의 필드의 모델을 뷰에 바인딩 시키고 모델만 고치는게 좋다고 듣기는 했음.. 그런데 필드의 모델로 갖고 있기에는 너무 적절치 않은 경우도 있는 것 같다. 예를 들어서 문서편집기를 만든다고 했을 때 블록지정된 텍스트 영역을 모델로 갖고 있어야 하는가? 이런 경우에는 차라리 필요한 경우에 필요한 패러미터를 한번만 보내는게 효율적으로 보임
3/4는 코드비하인드가 있냐없냐가 중요하다기보단 모델이 할일이랑 뷰가 할일이 섞이는게 문제인거라, 뷰가 할일을 코드 비하인드에서 하는건 아무런 문제가 없음.
유저컨트롤 내부의 데이터컨텍스트를 가져온다는게 위에걸 아래로 가져온다는건지 안에걸 밖으로가져온다는건지 좀 헷갈리는데... Relative Source 뭐 그런게 있던걸 기억하기는 하는데 뭐 한쫑은 좀 말이 안되고 다른쪽은 괜찮고.. 바로 뭐 생각나는건 아닌데 어디 best practice가 있긴 할거같음.
둘 다 필요한 경우가 발생했는데, 아직 배우는 단계라 시행착오가 좀 많은 것 같기도 함. 어디서 베스트 프랙티스 볼 수 있으면 나도 참 좋겠음. 교재도 없고 자료 찾기가 너무 어렵네..
아마 둘 다 발생한거면 곰곰히 생각해보면 한쪽이 잘못 생각했을거임... (이건 의존성이 순환했을거라 거의 확실)
안해본지 오래 돼서 아무튼 기억나는대로 이야기한거라 딴사람 말이 다르면 딴사람 말이 맞음
감사합니다 그래도 도움이 됐습니다
1. 케바케긴한데 메소드 하나로 처리가 되는 경우라면 커맨드를 한 개만 만듦. 커맨드에 파라미터를 넣는 건 별로 좋은 습관이 아님. 물론 예시로 넣느라 object일거라고 믿지만 int같은 명확한 자료형이더라도 몇번씩 고민하고 넣는데 진짜로 object를 넣은거면 당장 파라미터부터 지우는걸 권함.
2. Interaction은 자주 쓰는 편이지만 개인적으로 이벤트 트리거는 자주 쓰진 않음. 물론 이건 케바케가 심하고 이벤트 트리거를 자주 써야 하는 부류도 있으니 뭐가 정답이다 하는건 없음. Behavior는 컨트롤에 추가 동작을 부여해주는게 맞음. 일반적으론 ViewModel에서 처리해야 하는 기능이 아니면서, 컨트롤에 추가로 구현하고 싶은 기능이 있는데 이를 위해 새로 UserControl을 만들기엔 수지타산이 안 맞을 때 씀.
3. 그 UserControl이 어떨 때 쓰이는 것인지에 따라 많이 다름. 독립된 창이라 독자적인 ViewModel을 가지고 있을 수도 있고, 진짜 컨트롤 구현하는 느낌으로다가 만들어서 코드비하인드만 있을 수도 있는데... 좀 구체적인 케이스를 가져오면 자세히 답변해줄 수 있을 듯.
4. MVVM의 핵심은 View의 작업과 ViewModel의 작업을 분리하는 것. ViewModel과 연관이 없는 작업이라면, 그리고 다른 데서 재사용할 일이 없다면 코드비하인드가 정답이 되는 경우가 많음. 물론 이 경우도 "엄밀한" MVVM을 추구하는 사람이라면 Behavior나 Style 등으로 따로 빼서 구현하는 경우도 많지만 난 그렇게까진 안 하는 편.