WPF의 MVVM에 대한 프로젝트 구조

WPF의 MVVM에 대한 프로젝트 구조

---

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

지금 본 자습서에서 일반적으로 Model, ModelView 및 View 폴더가 있습니다.

Model에서는 데이터와 로직을 캡처하는 Person과 같은 클래스를 넣습니다.

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

편집 : 원래 게시물을 편집하여 예제 프로젝트 구조를 보냅니다. 이와 관련된 질문이 있습니다. 구성 방법 : App.config App.xaml MainWindow.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
• ViewModel /
  • CarViewModel.cs
  • DriverViewModel.cs
• 전망/
  • CarView.xaml
  • DriverView.xaml

I think the reason why it's popular is because some people will argue that you should be able to put Models, ViewModels and Views in different assemblies.

Also with this structure, you can easily add folders for other WPF stuffs: Converters/, Resources/, etc.

Within my team, we use this structure but we pluralize the names (so Models/ViewModels/Views).

However, most of the time, model classes are defined in other assemblies/namespace; in that case, we don't even have a Models/ folder.

For large projects, we add subfolders into the Models/, ViewModels/ and Views/

For the sake of completeness, it's worth mentioning that you may find a few people using a "feature driven" structure:

• Car/
  • CarModel.cs
  • CarViewModel.cs
  • CarView.xaml
• Driver/
  • DriverModel.cs
  • DriverViewModel.cs
  • DriverView.xaml

But it's very uncommon.

---

What I usualy have goes like this:

• Main Application (.exe) - Global Styles, etc
• Common Lib WPF - Base Classes and Helpers for WPF
• Common Lib General - Base Classes and Helpers for Models
• Infrastructure - Dependency Injection, Logging, etc
• Interfaces for VM
• Interfaces for M
• Several Libraries containing Views and corresponding ViewModels - Splitting here is possible as well
• Several Libraries containing Models

All dependencies are based on Interfaces only resolved via DI.

---

Friends, the solution I found for a problem similar to this was to create a separate project, the type WPF, I called Startup, only with App.xaml (and App.xaml.cs).

In it I refer to the project of the View and ViewModel. So the view has no dependence and ViewModel "sees" only the View and Business.

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

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