배우는 중인데,
모델로 만들기 애매한 경우에는 코드비하인드에서 작업해도 괜찮을거같은데 맞을까요?
예를 들면 현재 블록지정된 글자라거나..
콤보박스에서 선택한 글자 서식이라거나 이런 것도 모델으로 봐야하나요?
또는 커스텀으로 슬라이드형 패널을 만들었다면
버튼을 눌렀을때 조정되는 위치도 모델로 봐야하나요?
일단 예전에 웹개발만 좀 해봤을때는
제가 알기로는 모델이라는건 좀 더 데이터 뭉치같은 느낌이었는데.. 좀 혼란스럽습니다.
어디까지를 기준으로 보고 작업을 해야할지
사람 강박증 환자 만드는 패턴임
혹시 기준이 있을까요? 예제를 봐도 사람마다 코드 짜는 방식이 다 다르네요.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ ㄹㅇ ㅋㅋㅋ mvvm 패턴 쓰는곳마다 항상 이런 문의 엄청많은듯 ㅋㅋㅋㅋㅋㅋㅋ
코드 비하인드가 뭔데 데이터가 이곳저곳 옮겨다니면 모델이지 선택한 글자서식을 담을 통이 모델이지 그걸 콤보박스에 바인딩하고 인풋필드에서 칠떄 적용시킨다거나 앱종료할떄 저장한다거나 하는거지 걍 데이터는 다 모델이다
class AppSetting { <-- appsetting 이라는 모델임 Font font {get;set;} } appsetting.font 를 셀렉트박스에 바인딩 inputfield 텍스트칠때 적용 저장할떄 모델만 저장 serialize(appsetting).save(dirPath) 알겟냐???
그런걸 우린 스타일이라고 부르고 있지
일반적으로 MVVM에서 모델이라 함은 비즈니스 로직 및 그에 관련된 데이터를 뜻함. 뷰에서 자기 혼자 관리하려고 쓰는 데이터들은 모델로 안침. 그리고 뷰에서는 UI 로직만 처리하고, 뷰모델이 모델의 데이터를 가공해서 UI에게 넘겨주는 역할을 함. 이 관점에서 봤을 때, 예시로 든 케이스들은 모두 모델이 아님.
근데 이걸 코드비하인드에서 작업해도 되는가는 생각을 좀 해봐야 함. 블록지정을 예시로 들면 다음과 같음. 이걸 비즈니스 로직/데이터를 전혀 거치지 않고 뷰에서 처리해도 된다면 코드비하인드에서 처리해도 되지만, 사용자 입력이 들어간다거나 모델의 데이터/로직이 엮여있다거나 하면 이건 더 이상 뷰에서 독자적으로 처리할 문제가 아니고 따라서 뷰모델에서 다루도록 적절한 방법을 제공해야 함. 그것이 WPF에서는 보통 커맨드와 데이터 바인딩임.
마지막으로 상기의 문제점 때문에 코드비하인드에 무언가를 쓰는 것 자체를 민감하게 여기는 사람이 많음. 이런 사람들은 UI only logic이더라도 Behavior나 Custom control, Trigger 등등의 방법으로 매우 적극적으로 코드비하인드를 제거하려고 함. 이런 시도를 하면 자연스럽게 MVVM이 지켜지기 때문. 하지만 난 개인적으론 "MVVM 원칙을 잘 지킬 수 있다면" 코드비하인드에 로직을 작성하는건 나쁘게 보진 않음. 이건 취향차이임.
항상 좋은 말씀 감사합니다!