programing

WPF의 MVVM 프로젝트 구조

muds 2023. 4. 11. 22:42
반응형

WPF의 MVVM 프로젝트 구조

WPF에서 MVVM을 사용할 때 얻게 되는 프로젝트 구조는 무엇입니까?

지금 본 튜토리얼에서는 보통 모델, 뷰 모델 및 뷰 폴더가 있습니다.

모델에는 개인과 같은 데이터 및 논리를 캡처하는 클래스를 넣습니다.

ViewModel에서는 모델에 정의된 클래스를 인스턴스화합니다.보기에는 .xaml 파일이 포함되어 있습니다.

편집: 원래 투고를 편집하여 프로젝트 구조의 예를 보냅니다.이것과 관련하여 질문이 있습니다.구성 방법: App.config App.xaml Main Window.xaml

지금처럼 밖에 둘까요, 아니면 폴더에 둘까요?

여기에 이미지 설명 입력

일반 또는 공통 폴더 레이아웃을 설명했습니다.경험에 비추어 볼 때 모델 데이터 유형에 대해 다음과 같은 별도의 폴더(또는 대규모 응용 프로그램에서는 프로젝트)를 추가하는 것을 선호합니다.Person당신이 말한 수업.제가 이렇게 하는 이유는 이것이 종종 가장 큰 프로젝트 중 하나가 되기 때문입니다.또한 다음 하위 폴더로 분할했습니다.

DataTypes
    Collections
    Enums
    Interfaces

또, 애플리케이션용의 폴더(또는 대규모 애플리케이션의 프로젝트)도 따로 가지고 있습니다.Converter클래스, 확장 메서드 클래스, 유틸리티(또는 서비스) 클래스.마지막으로 애플리케이션 폴더 구조와 거의 일치하는 테스트 프로젝트가 있습니다.내 폴더는 대략 다음과 같습니다.

Solution

    Third Party Libraries <<< (Solution Folder)

    StartUp Project
        Images
        Resources

    Converters

    DataTypes
        Collections
        Enums
        Interfaces <<< (For Data Type classes)

    Extensions

    Models
        Data Controllers
        Data Providers
        Interfaces <<< (For swapping Model classes out in test projects)

    Utilities (Or Services)
        Interfaces <<< (For swapping Utilities classes out in test projects)

    View Models
        Commands

    Views
        Attached Properties
        Controls

업데이트 >>>

폴더와 마찬가지로 프로젝트도 분리 수준만 제공합니다.또한 응용 프로그램 네임스페이스를 매핑하는 데도 도움이 됩니다.예를 들어, 의 코드 클래스Collections폴더/프로젝트는ApplicationName.DataTypes.Collections네임스페이스.의 클래스Data Providers폴더/프로젝트에는ApplicationName.Models.DataProviders네임스페이스.

게다가 대규모 애플리케이션에서는, 이 계층내의 프로젝트명의 위치로부터 프로젝트명이 취득됩니다.예를 들어, 나의DataTypes실제로 프로젝트라고 불립니다.ApplicationName.DataTypes그리고 나의Models프로젝트 이름ApplicationName.Models.그Collections그리고.DataProviders부품은 폴더이며, 두 번째 수준 이후의 모든 항목과 함께 표시됩니다. Enums,Images,Commands,기타.

대부분의 사람들은 당신이 말한 "표준" 구조를 사용합니다.

  • 모델/
    • CarModel.cs
    • DriverModel.cs
  • 모델 표시/
    • CarViewModel.cs
    • DriverViewModel.cs
  • 표시/
    • CarView.xaml
    • DriverView.xaml

인기 있는 이유는 모델, 뷰 모델, 뷰를 다른 어셈블리에 넣을 수 있어야 한다고 주장하는 사람들이 있기 때문이라고 생각합니다.

, 이에서는, WPF( 「 」, 「 」, 「 」, 「 WPF 」)의 할 수 .Converters/,Resources/ 등등.

저희 팀에서는 이 구조를 사용하고 있습니다만, 이름을 복수화하고 있습니다(그래서 모델/View Models/Views).

모델 클래스는 다른 되어 있습니다. 클래스는 이 경우 모델 클래스는Models/더입니니다다

합니다.Models/,ViewModels/ ★★★★★★★★★★★★★★★★★」Views/

완성도를 높이기 위해 다음과 같은 "기능 중심" 구조를 사용하는 사용자를 찾을 수 있다는 점을 언급할 필요가 있습니다.

  • ★★★★★★★/
    • CarModel.cs
    • CarViewModel.cs
    • CarView.xaml
  • ★★★★★★★/
    • DriverModel.cs
    • DriverViewModel.cs
    • DriverView.xaml

하지만 아주 드문 일이에요.

제가 평소에 가지고 있는 것은 다음과 같습니다.

  • 메인 애플리케이션(.exe) - 글로벌 스타일 등
  • Common Lib WPF - WPF의 기본 클래스 및 도우미
  • Common Lib General - 모델의 기본 클래스 및 도우미
  • 인프라스트럭처 - 의존관계 주입, 로깅 등
  • VM용 인터페이스
  • M의 인터페이스
  • 보기 및 해당 보기 모델이 포함된 여러 라이브러리 - 여기에서 분할할 수도 있습니다.
  • 모델이 포함된 여러 라이브러리

모든 의존관계는 DI를 통해서만 해결되는 인터페이스를 기반으로 합니다.

여러분, 이와 유사한 문제에 대해 제가 발견한 해결책은 App.xaml(및 App.xaml.cs)만을 사용하여 WPF 유형으로 Startup이라고 하는 별도의 프로젝트를 만드는 것이었습니다.

여기서 View 및 View Model 프로젝트를 참조합니다.따라서 뷰는 종속성이 없으며 View Model은 뷰와 비즈니스만 "인식"합니다.

App.xaml.cs에서 내 Main Window를 선언하고 인스턴스화한 다음 내 앱의 몇 가지 기본 속성을 로드하고 로그인 페이지로 이동합니다(창과 그 안에서 여러 페이지를 브라우징하고 있습니다).

여기에 이미지 설명 입력

언급URL : https://stackoverflow.com/questions/18825888/project-structure-for-mvvm-in-wpf

반응형