[사례] 범용적인 WPF 앱 아키텍처

WPF 라고 썼지만 사실 뭐… WPF에 국한된 이야기는 아닙니다.

직전 회사에서 WPF 앱이 필요해서 사용해보고 적용했던 클라이언트 앱 아키텍처입니다.

재미난 점은

  • 모든 모델(데이터 홀더)들이 ObservableObject(INotifyPropertyChanged의)인 점
    (이렇기에 새 모델 인스턴스 발행 없이 부분 업데이트 가능)

  • (모델들의) 데이터를 인메모리 DbContext로 보관 및 이를 전역적으로 사용한 점
    (DbContext는 인메모리, 싱글톤입니다. Database로 안쓰고 In-process에서 모델간 관계 매핑용으로 사용하기 위해 활용한 사례입니다. ORM이라는 이름답게…)
    (인메모리는 사실 테스트용이라… 매우 실험적인 사례입니다. 적용한다면 많은 고심 필요. 제 시나리오에서는 성공)

  • 중앙 데이터 보관소 (인메모리 dbContext)에 대한 읽고, 쓰기 분리
    (React에서 페이스북이 약팔이하는 어쩌고 저쩌고 패턴도 이런 단방향 모델인데… 거기는 데이터가 조금만 바껴도 불변개체로 인스턴스 새로 발행합니다. 미친짓이죠… 컬렉션에서 그랬다가 메모리랑 뷰 업데이트 부담 작살나는 형태… 여기서는 ObservableObject이기에 바뀐 속성만 그대로 업데이트)

  • ICommand들은 Server나 특정 비지니스 로직이 성공하면 이를 바탕으로 In-memory DbContext를 업데이트 합니다.

  • AppStateReader는 DbContext를 Read-only로 투영합니다. 내부에서 담고 있는 데이터들이 ObservableObject이기에 걍 그거 Binding해서 사용합니다.

  • ViewModel은 View 로직 추상화,
    AppStateReader와 Command들 생성자로 받아서 사용.

입니다.

이러면 데이터들이 중앙화 되기에 모든 화면에 데이터 상태를 동기화할 수 있습니다.
제가 WPF 쓰려고 참고용 앱들 보니까 두 화면에 보여지는 특정 모델의 상태를 모든곳에서 업데이트하려고 In-process 메신저 같은거 많이 쓰던데… 고건 매우 별로라서 이러한 아키텍처를 택했습니다.

좋아요 5

좋은 내용 감사합니다!
그런데 궁금한 부분이 생겼는데, 어떤 부분에 대해 고심해봐야 할까요? :thinking:

좋아요 1

맵핑이 잘 안될수도 있는것 같은데 저는 그런 현상은 없었습니다.

Sqlite용을 인메모리로 쓰는게 관건인듯요.

그리고 제일 중요한건 인메모리 자체가 이런 용도가 아니라서…

좋아요 1