이번에 이상 깊게 배우게 된 것은
- 템플릿 내보내기
- 솔루션 폴더 생성
두 가지 였습니다.
github 같은데서 오픈소스 클론받아서 열어보면 솔루션안에 폴더가 여러개가 있는걸로 보였는데 실제로 clone된 directory를 보면 폴더별로 나뉘어져있지 않아서 이건 어떻게하는건가 궁금했었습니다.
이번에 알게되어 좋았습니다.
CustomControl을 템플릿 프로젝트 내보내기를 통해 템플릿으로 관리하여 반복되는 노가다 작업을 최대한 줄일 수 있었던 것이 좋았습니다. 2017년도에 템플릿 내보내기를 아는 형님 통해서 알아뒀었는데 6년만에 꺼내든 지식이었어서 거의 새로 배운 것처럼 신선했습니다.
그래서 회사에서 새로 진행되는 솔루션을 이번에 스터디에서 배운 구조로 모두 변경했습니다.
- 솔루션
– 폴더
—CustomControl 뷰 프로젝트
—CustomControl 뷰모델 프로젝트
—CustomControl 뷰모델 Xunit 테스트 프로젝트
– 폴더
—CustomControl 뷰 프로젝트
—CustomControl 뷰모델 프로젝트
—CustomControl 뷰모델 Xunit 테스트 프로젝트
– 폴더
—CustomControl 뷰 프로젝트
—CustomControl 뷰모델 프로젝트
—CustomControl 뷰모델 Xunit 테스트 프로젝트
…
이런식으로 폴더마다 CustomControl의 뷰와 뷰모델 프로젝트까지 완전히 나누고, 뷰모델도 혹시몰라 유닛테스트가 가능하도록 했습니다.
다만 조금 차이가 있게 변형한 것은, Prism을 사용하지 않고 다른방식으로 했습니다.
@aroooong 님의 pc kakaotalk 샘플에 mapping으로 뷰와 뷰모델은 데이터 템플릿으로 관리하는 방법입니다.
WPFKakaoTalk/Mappings.xaml at master · tyeom/WPFKakaoTalk (github.com)
이 방식을 이용하면 prism을 이용하지 않고 뷰와 뷰모델은 resourcedictionary 안에서 매핑할 수 있습니다. CommunityToolkit 만으로 가능하다는 의미입니다. (CommunityToolkit 안에 Generic Host가 이미 있으므로)
원래 저도 ViewLocator(ViewModelLocator 아님)와 네이밍 패턴으로 하는 방식을 선호했으나, 유지보수 차원에서 명시적으로 하려면 아무래도 스터디에서 배웠던 방식이던, 지금처럼 리소스로 관리하는 방식이던 명시적으로 어딘가에서 표현하는 방식이 있어야겠다고 생각을 조금 바꾸게 되었습니다.
언젠가 ViewLocator 방식도 다시 쓸 날이 오겠지만 이번에는 이렇게 진행해보려고 합니다.
또한 AvaloniaUI도 이런 CustomControl 방식을 해보고 싶어서 시도했는데 잘 되는 것 같긴합니다.
좋은 아키텍쳐 배워갑니다
감사합니다.