Структура проекта для MVVM в WPF

Какова структура проекта, в результате которой вы используете MVVM в WPF?

Из учебников, которые я видел сейчас, у них обычно есть папки: Model, ModelView и Посмотреть.

В модели вы помещаете классы вроде Person, например, которые захватывают данные и логики.

В ModelView вы создаете классы, определенные в модели. Вид содержит .xaml.

Изменить: я редактирую свое оригинальное сообщение, чтобы отправить примерную структуру проекта. У меня есть вопрос, связанный с этим. Как это организовать? App.config App.xaml MainWindow.xaml

Должен ли я оставить их снаружи, как сейчас, или я должен поместить их в какую-то папку?

enter image description here

Ответы

Ответ 1

Вы описали обычную или общую папку. По опыту я предпочитаю добавлять отдельную папку (или проект в больших приложениях) для типа данных модели, например, типичный класс 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 и т.д.

Ответ 2

Большинство людей используют стандартную структуру, о которой вы говорили:

  • Модель /
    • CarModel.cs
    • DriverModel.cs
  • ViewModel/
    • CarViewModel.cs
    • DriverViewModel.cs
  • Вид /
    • CarView.xaml
    • DriverView.xaml

Я думаю, причина, по которой это популярно, состоит в том, что некоторые люди будут утверждать, что вы должны ставить Модели, ViewModels и Views в разные сборки.

Также с этой структурой вы можете легко добавлять папки для других продуктов WPF: Converters/, Resources/ и т.д.

В моей команде мы используем эту структуру, но мы дублируем имена (так что модели /ViewModels/Views ).

Однако большую часть времени классы моделей определяются в других сборках/пространствах имен; в этом случае у нас даже нет папки Models/.

Для больших проектов мы добавляем подпапки в Models/, ViewModels/ и Views/

Для полноты, стоит упомянуть, что вы можете найти несколько человек, использующих структуру, управляемую функцией:

  • Автомобиль /
    • CarModel.cs
    • CarViewModel.cs
    • CarView.xaml
  • Водитель /
    • DriverModel.cs
    • DriverViewModel.cs
    • DriverView.xaml

Но это очень необычно.

Ответ 3

Друзья, решение, которое я нашел для проблемы, похожее на это, - создать отдельный проект, тип WPF, я назвал Startup, только с App.xaml(и App.xaml.cs).

В нем я ссылаюсь на проект View и ViewModel. Таким образом, представление не имеет никакой зависимости, и ViewModel "видит" только вид и бизнес.

В App.xaml.cs объявляйте и создайте экземпляр моего MainWindow, затем загрузите некоторые основные свойства моего приложения и перейдите на страницу Login (я работаю с окном и просматриваю несколько страниц внутри них).

введите описание изображения здесь

Ответ 4

Что я обычно делаю так:

  • Основное приложение (.exe) - Глобальные стили и т.д.
  • Common Lib WPF - базовые классы и помощники для WPF
  • Common Lib General - базовые классы и помощники для моделей
  • Инфраструктура - Инъекция зависимостей, ведение журнала и т.д.
  • Интерфейсы для VM
  • Интерфейсы для M
  • Возможны также несколько библиотек, содержащих Views и соответствующие ViewModels.
  • Несколько библиотек, содержащих модели

Все зависимости основаны на интерфейсах, разрешенных только через DI.