IoC,DI와 Behavior에 대해서 궁금한 것이 있어서 질문합니당..

🖥️ UI/UX 프로그래밍 Q&A WPF Q&A
1

안녕하세욥,
IoC와 Behavior 에 대해 조금 더 이해를 하고 싶어서 질문드립니다…
공부를 하면서 조금씩 이해가 되는 부분이 늘고 있는데 더 잘 알고 싶어서 여쭤봅니당…
–IoC
IoC 와 의존성 주입(DI)을 같이 묶어서? 이해를 해보려 했습니다.
의존성 주입은 한 객체에서 필요한 다른객체를 외부에서 할당해주는 것이라고 이해했습니다.
예를 들어, A객체에서 B객체를 사용한다고 가정했을때
A객체의 생성자에서 B객체를 받아 A객체 안에있는 변수에 할당하는 것이죠
또 C라는 객체가 D라는 인터페이스를 상속받아 구현하면 이것도 의존성 주입이라고 이해했습니다.

–Behavior
Behavior 는 뷰에서 사용되는 컨트롤의 이벤트에 따른 조작(커맨드연결)을 편리하기 위해 사용하는 개념이라고 이해했습니다.
WPF xaml에서 Behavior를 통해 컨트롤에 대한 조작을 쉽게 관리할 수 있는 것 같습니다.
제가 강의를 보며 해본 예제와 찾아본 자료에서 xaml태그에서 사용을 하더라구요,

궁금한 것은

  1. 제가 위 두개념에 대해서 이해를 옳은?? 방향으로 하고있는 걸까요?

2.MVVM패턴을 더 잘 구현하기 위해서는 Behavior 와 IoC,DI를 코드로 구현하여 View에서는
신경쓰지 않도록 하는게 맞다고 생각을 했는데
맞다면 Behavior 와 IoC를 작성할 때 어떠한 방식으로 작성하나요?
Behavior를 구현하다고 하면 Behavior 클래스 하나당 한 컨트롤에서 발생하는 이벤트를 처리하는 기능들을 정의는 방식으로 하면 되는 것일까요??

5개의 좋아요
2

  1. 네. 대략 방향성은 맞는 것 같습니다.

글쎄요. Behavior는 Binding으로 해결할 수 없는 경우 저는 만들고 사용하는데 경험 상 그런 경우가 흔치 는 않은 것 같습니다. 바인딩으로 안되는 것 또한 Community Toolkit 등에서 제공하는 Behavior를 이용하는 것으로 대부분 해결되었습니다.

MVVM 패턴에서 직접적으로는 Behavior와 IoC(또는 DI)(와는 상관이 없습니다. 종속성 주입은 ViewModel 만들 때 필요합니다. (필요 없다면 안써도 됩니다)

MVVM 패턴은 다음의 원칙으로 만들었다면 MVVM 패턴으로 만들었다고 할 수 있습니다.

  1. View는 화면 로직을 가진다. 서비스 로직을 가지지 않는다. ViewModel을 참조한다. Model을 참조한다.
  2. ViewModel은 서비스 로직을 가진다. View를 참조하지 않는다. Model을 참조한다.
  3. Model은 서비스 엔터티 를 가진다. ViewModel 및 View를 참조하지 않는다.

ViewModel를 포함한 각종 서비스를 좀 더 편리하게 가져다 쓰는 방법론이 IoC 이고요. IoC에서 대표적으로 사용하는 기술이 DI 입니다.

Behavior는 이벤트 (또는 속성으로 드러나지 않는 메소드 기능 등을 포함한)를 이용해 새로운 기능을 추가할 때 사용합니다. 그러니까 XAML에서 화면 로직을 최소화 하기 위한 좋은 툴이긴 한데 화면 로직(코드)를 배제할 필요도 없습니다. 화면 관련된 로직은 View에 위치하니까 MVVM을 위배하지 않습니다.

9개의 좋아요
3

IoC를 코드로 구현하는 방법이 "의존성 주입"입니다.

IoC 는 워커객체로부터 행위 결정권(Control)을 뺏는 것입니다.
워커 객체에게 행위 결정권을 제한한다는 점에서 "커맨드 패턴"과 유사합니다. (커맨드 패턴은 아예 행위 결정권을 주지 않기 때문에 더 엄격한 주도권 관리입니다)

그런데, 의존성 주입할 때, 인터페이스를 쓰는 것은 약간 다른 취지입니다.
특정 부류의 객체(class)를 주입하는 것보다, 동일한 행위를 가진 객체면 어떤 부류의 객체라도 쓸 수 있게 만들기 때문에, 코드의 재사용성이 높아지는 이점이 있습니다.

예를 들어, Speaker 에게 Human을 주입하는 것도 의존성 주입이며, ISpeakable 을 주입하는 것도 의존성 주입입니다. 그런데, Human 을 주입하는 코드를 적어 놓으면, 나중에 말하는 앵무새가 필요한 경우, Speaker 코드를 수정해야 합니다. 이를 방지하기 위해, ISpeakable 객체를 주입받도록 구현해놓으면, 그게 고양이든, 닭이든, 앵무새든, ISpeakable 을 구현하기만 하면, Speaker 코드 수정없이 주입해도 문제가 안생기고, 그 만큼 과거의 코드를 유지보수하는게 편해집니다.

이는 애자일 운동이 주장하는 SOLID의 OCP에 충실한 객체 설계 방법입니다. 의존객체와 피의존 객체사이의 관계를 늣슨하게 맺게 하는 것으로, 닷넷 문서에서는 이를 "느슨한 결합(Loosely Coupled)"이라고 표현합니다.

MVVM은 소프트웨어 건축방법(아키텍쳐) 중에 하나로, 소프트웨어를 V, VM, M 요소로 나눠서 설계하라는 것입니다. 집을 지을 때, 집의 구조를 자재 - 시공방법 - 외관으로 나누는 것과 크게 다르지 않습니다.

건축방법이 MVVM이든, MVC 든, MVP 든 뭐가 되었던 간에, 한 번 쓴 코드를 또 고치고, 자꾸 고치고 한번 더 고치고 하고 싶지 않다면, 가급적 느슨하게 결합시키는게 좋다는 취지입니다.

닷넷에서는 의존성 주입이 방대하게 쓰이는데, 대부분 "의존성 주입기(Dependency Injector)"의 도움을 받습니다. 의존성 주입기가 있으면, 주입받는 코드만 쓰면되고, 주입하는 코드는 생략할 수 있거든요. 참고로, 닷넷에서는 "의존성 주입기"를 "서비스 컨테이너"라고 부르는 경우가 많습니다.

Bahavior 는 프레임워크가 제공하는 콘트롤의 기본 행위에 추가적으로 넣고 싶은 (기본)행위가 있을 때 사용합니다. 예를 들어, 모바일 앱인 경우, 버트 콘트롤은 클릭했을 때, 진동을 하지 않습니다.
특정 버튼만 진동하기를 원한다면, 그 버튼의 클릭 이벤트에 진동을 하는 핸들러를 연결하면 되지만, Behavior 로 정의하면 모든 버튼이 진동하게 됩니다.

이 또한 느슨한 결합으로 설계를 하면, 나중에 진동이 아니라, “띵동” 소리를 내도록 변경해도, 기존의 코드를 손을 안대도 되는 것이죠. 심지어, A 뷰에서는 진동, B 뷰에서는 "띵동"으로 선택할 수도 있구요.

10개의 좋아요
4

좋은 설명해주셔 감사합니다
뭔가 팍 뚫린 느낌이네요 !!!

4개의 좋아요
5

자세한 설명 너무 감사합니다!
두고두고 볼 설명인것 같아요 :slight_smile:

5개의 좋아요
6

의견

  1. Behavior 는 컨트롤의 확장입니다.

c#의 확장 메소드를 옮겨놓은 것과 동일한 효과입니다.

6개의 좋아요
7

첨언 드리자면,

어차피 중요한 것은 제대로 동작하고, 소스 코드의 유지를 최소화 하자는 것입니다.

MVVM에 대한 사람의 의견이 각자 다르기에

View에서 ViewModel을 참조하는 것이 위배라는 분도 있고(오로지 XAML에서 Binding 으로만 처리)

이 경우, 대표적인 해결 방안으로 ViewLocator라는 개념으로 View와 ViewModel의 관계를 끊어내고 View와 ViewModel의 네이밍 패턴을 통하여 구현합니다.

View에서 ViewModel을 참조해도 위배가 아니라는 분도 있습니다.(View의 Code-Behind에서 ViewModel이 참조되는 형태)

대표적으로 .NET에서 유명한 MVVM Framework인 ReactiveUI의 공식 문서에 위와 같은 내용이 기재되어 있습니다.

중요한 것은 윗분들 답변처럼 도구란 수정을 최소하하는 목적으로 이런저런 도구들을 사용하는 것이지,

맥락을 너무 깊게 가져가시다가 어느 한 쪽이 정답이라는 생각을 가지고 생각을 정리하게 되면 다른 의견은 받아들이지 못할 듯합니다.

저는 개인적으로 IT에는 오답이 없다고 생각합니다.

Windows Forms에서 Button Click Event 하나에 50000000줄이 들어있더라도 그것이 비지니스를 똑바로 구현하고 있고, 이전보다 더 나은 자동화를 추구했다면 틀린 소스 코드가 아니라고 생각합니다.

적어도 손으로 하나하나 하던 시절보다는 빠르기 때문이지요.

즉 개발 업계 자체에도 도구는 입맛에 맞춰서 사용할 뿐, 어떤 것은 분명히 틀린 개념입니다. 라는 것은 없는 것 같기 때문에, 이런 도구들에 세부적인 정리보다는 방향만 가져가시는 걸 추천드립니다.

5개의 좋아요
8

감사합니다 제가 도구를 너무 쓸데없이 깊게생각 한 것 같네요 ㅎㅎ
생각 정리하는데 많은 도움이 되었습니다!

4개의 좋아요