다른 응용 프로그램 프레임 워크에서 사용할 수 있도록 데이터 모델을 설계하는 방법은 무엇입니까?

Question

MVVM 디자인 및 데이터 바인딩을 기반으로하는 WPF GUI 응용 프로그램이 있습니다. 이제 Windows 서비스, 콘솔 UI 앱 또는 WinForms 앱에서 핵심 코드 (즉, 데이터 모델)를 재사용하고 싶습니다.

그런 디자인이 합리적입니까? 그렇다면 함정은 무엇입니까?
대신 독립형 데이터 모델을 만들고 래퍼를 통해 WPF를 인터페이스해야합니까?

UPDATE :

미안 해요, 난 더 정확한되어 있어야합니다. 내가 분명히 말하자면, 나는 모듈성의 문제를 의심하지 않는다.) 내 관심사는 현재의 DataModel이 INotifyPropertyChanged을 구현하고, DispatcherTimers 등을 사용하는 것으로 귀결된다. - 그 모든 것 비 GUI이지만 WPF는 여전히이다. 모델의 비즈니스 로직은이를 기반으로합니다.

(GUI가 아닌 WPF) 디자인은 앞에서 설명한 경우 재사용이 가능합니까? 아니면 WPF에 대한 참조가 전혀 필요하지 않을 때까지 추상화해야합니까?

Answer 1

예, 이것은 완벽하게 수용 가능하며 대부분의 경우 바람직합니다.

당신이 MVVM 응용 프로그램을 구축

는, 적어도 3 개 공식적인 층에 있어야합니다 :

• 프리젠 테이션 WPF, UI, XAML, 행동. 그 모든 것들. 재사용 불가
• 응용 프로그램 응용 프로그램 규칙을 지원하는보기 모델 및 구조. 그 모든 것들. 재사용을 목적으로하지 않음
• 기초 데이터베이스 액세스, 비즈니스 개체. 도메인 특정 알고리즘. 이상적이 비트는 재사용 어딘가에

기초 층 영리 비트이다이어야한다. 이것은 응용 프로그램 샌드위치의 고기가있는 곳입니다. 이것이 UI 기술에 완전히 불가 지론이되는 것은 완벽합니다. WPF, winforms, ASP. UI가 필요하지 않아야합니다. 질문 업데이트

편집 : 때때로 당신은 결과의 그룹화/필터링 뷰 모델에 CollectionViewSource을 필요로하기 때문에

WPF에 대한 모든 참조를 제거하기는 어렵다. WPF 클래스입니다.

'wpf를 참조하지 마라.'라는 우려를 표출하는 것은 매우 유혹적이며 그로 인해 어려움을 겪을 수 있습니다. 대신, 당신이 입력하는 행동의 유형으로 훈련을 시도하십시오. 당신이보기 모델에서 '영리한'(도메인) 코드를 작성하는 경우, 그것을 비즈니스 오브젝트 방법 또는 확장으로 기초 계층으로 이동하십시오. 마찬가지로, IValueConverter을 종종 구현하는 경우 뷰 모델을 더 잘 활용해야합니다.

확실한 점은 기초 레이어가 절대로 WPF를 참조해서는 안된다는 것입니다.

Answer 2

이러한 디자인은 매우 합리적입니다! 모델을 포함 할 수있는 WPF, WinRT, ASP MVC 등 모든 .NET 기술에 대해 이식 가능한 C# 라이브러리를 만들 수 있습니다. 분명히 이러한 휴대용 모델을 뷰 모델로 포장해야하지만 IPropertyChanged는 모든 XAML 형식으로 구현됩니다.