저희 팀은 현재 xaml단에서 ICommand를 사용하시는 분도 계시고 저같은 경우에는 .cs에 메소드만 넣고 ViewModel로 넘기는 식으로 사용 한다거나 팀 내에서 MVVM을 다양하게 사용하고있습니다.
동료들과 어떻게 하면 더 나은 MVVM을 사용할수있고, 서로 통일도하며, 어떻게 하면 더 나은 코드를 작성할 수 있을까 고민 끝에 나온 방법은 프리즘을 사용해보면 어떨까? 하는 생각이 들어 몇가지 테스트를 해봤는데요. 코드비하인드가 깔끔해지니 MVVM을 완벽히 사용하기엔 좋긴 하더라구요
여기서 궁금한 점은
현업에서 프리즘을 많이 사용 하시는지? 아니면 사용해보신적 있으신지?
1-1. 사용하신다면 어떤 장점에 맘에드셔서 사용하시는지?
1-2. 사용하지 않으신다면 어떤 걸 사용하시는지? 아니면 사용할 필요를 못 느끼시는지?
테스트중 sender,e 부분을 못찾았는데… 프리즘기능에 sender, e를 받아오는 부분이 있는지?
→ 찾아보니까 어떤 글에서는 프리즘 기능사용하지 않고 ICommand를 통해 받아오더라구요
MVVM방식을 사용하면 ViewModel등 다른 부분이 코드가 많이 복잡해지는데, 프리즘을 사용하시는분들 중 에는 정리하시는 방식이 따로있으신지?
프리즘을 사용하지 않으시더라도 ViewModel정리방법이 따로 있으신지?
→ 저의경우에는 region으로 Method와 buttonMethod를 분리해서 보고있습니다.
이상입니다.
저도 다른 많은 글들을 보니 댓글을 달까 말까 고민되던 글이 많았는데, 그냥 사용만 해보셨으면 어떤 느낌이 였는지 소감 한 줄 정도만 써주셔도 감사 할 것 같습니다.
Prism 라이브러리를 사용해본 적이 있습니다.
1-1. 기존에 이미 사용중이었는데 아마 Dependency Injection이 주 원인이었던 것 같아요.
말씀하신 것이 정확히 어디부분인지 모르겠지만 XAML에서 ViewModel의 Command로 이벤트 연결하는 것은 기능은 Prism 기능이 아니라 Behavior(또는 Interaction) 기능 중 하나입니다
(이 페이지의 Prism에서는 Interaction.Triggers로 소개하고 있는데 사용중인 프로젝트가 .Net Framework이 아닌 .Net 5 이상이라면 이 포스트와 같이 NuGet PKG를 이용할 수 있습니다).
여기에 PassEventArgs... 이름을 갖는 bool 속성이 있는데, 이 값을 true로 주면 ViewModel에서 e를 받을 수 있습니다(받기 위해서 Command의 Action<T>로 Event Argument 타입을 넣어야 합니다).
3-4. Prism이 드라마틱하게 코드 양을 줄여주는 것이 아니기 때문에 굳이 Prism으로 한정할 필요는 없을 것 같아요.
저의 경우, ViewModel의 코드를 최대한 500자를 넘기지 않도록 작성하고 있습니다.
적은 양의 스크롤과 표준주석을 이용하면 Region 보다 더 가독성이 좋아집니다.
그리고 코드를 작성할 때 닷넷의 기본 규칙이 있는데 이를 활용하면 더 도움이 됩니다.
그 중에서도 하나를 꼽으면 SA1201 규칙을 추천하는데, 그 이유가 클래스(또는 구조체) 내에서 초기화 순서대로 각각의 위치를 잡아줄 수 있도록 합니다.
예를들면 아래와 같이 Field는 반드시 생성자보다 앞에 나와야하고 Property는 반드시 생성자보다 뒤에 나와야한다 등입니다.
이런 규칙을 적용하면 어떤 파일을 보더라도 이 클래스가 어떻게 초기화가 이뤄지는지를 위에서 아래로 읽을 수 있어 상당히 도움이 됩니다.
마무리하면 Prism을 사용하시던, 그렇지 않으시던 코드 품질이 획기적으로 좋아지는 것은 아니기 때문에 사용성이나 학습하는 난이도 등을 고려해서 적용하면 좋을 것 같아요.
다만, 사용하는 WPF 프로젝트가 닷넷 프레임워크 기반이면 편의성이 많이 향상되기에 현재 어떤 라이브러리도 사용중이 아니라면 추천합니다.