Приложение Prism 4 WPF - реализована архитектура решений с использованием шаблонов MVVM, репозиториев и единиц работы - PullRequest
6 голосов
/ 13 января 2012

Я новичок в .Net и пытаюсь чему-то научиться.Я пытаюсь разработать приложение Prism4 WPF с

  1. Visual Studio CSharp 2010 Express Edition,
  2. Prism v4,
  3. Unity как IoC,
  4. SQL Server CE как хранилище данных.

Я много изучал (?) И под влиянием , и , и других, и решилреализовать шаблоны MVVM, Repository и UnitofWork.Это приложение будет настольным приложением с одним пользователем (я: -)

Итак, я создал решение со следующими проектами:

  1. Оболочка (макет приложения и запусклогика)
  2. Общий (Инфраструктура приложения и логика рабочего процесса)
  3. BusinessModuleA (Представления и ViewModels)
  4. BusinessModuleA.Model (Бизнес-объекты - POCO)
  5. BusinessModuleA.Data (хранилища, доступ к данным (EF?))
  6. BusinessModuleB (представления и модели представления)
  7. BusinessModuleB.Model (бизнес-объекты - POCO)
  8. BusinessModuleB.Data (хранилища), Доступ к данным (EF?))

Мои вопросы:

  1. Какие проекты должны ссылаться на какие проекты?
  2. Если я внедряю репозитории в BusinessModuleX.Data ', что очевидно, где я должен определить IRepositories?
  3. Где я должен определить IUnitOfWork и где я должен реализовать UnitOfWork?
  4. Это нормально, если я использую UnitOfWork и Reв моих ViewModels?Instict говорит, что это плохой дизайн.
  5. Если (4) выше плохо, то ViewModel должен получать данные через сервисный уровень (другой проект?).Затем, как мы можем отслеживать изменения в сущностях, чтобы вызывать соответствующие методы CRUD для этих объектов на уровне обслуживания?
  6. Имеет ли что-нибудь из этого смысл или я упускаю общую картину?

Хорошо, может быть, я не дал понять, чего именно хотел в своем первом посте.Там не так много ответов.Я все еще ищу ответы, потому что, хотя то, что предложил @Rachel, может быть эффективным для насущных потребностей, я хочу быть осторожным, чтобы не загнать себя в угол.У меня есть Access Db, который я разработал для личного использования в Office, и который стал своего рода успехом, и теперь его используют более 50 пользователей.Вначале поддержка и изменение базы кода доступа были довольно просты, но по мере развития приложения они начали разваливаться.Вот почему я решил переписать все в .Net / Wpf / Prism и хочу убедиться, что я правильно понял базовый дизайн.

Пожалуйста, обсудите.

Тем временем я пришелс это ...

Ответы [ 2 ]

4 голосов
/ 13 января 2012

Прежде всего, я бы немного упростил ваш список проектов до Shell, Common, ModuleA и ModuleB.Внутри каждого проекта у меня есть подпапки, чтобы указать, где все находится.Например, ModuleA можно разделить на папки для Views, ViewModels и Models

Я бы поместил все интерфейсы и глобальные общие объекты, такие как IUnitOfWork, в ваш проект Common, поскольку он будет использоваться всеми модулями.

То, как вы реализуете IUnitOfWork, и ваш Repositories, вероятно, зависит от того, какие у вас модули.

  • Если все ваше приложение связано с одной базой данных или совместно использует объекты базы данных, то я, вероятно, создам еще два проекта для DataAccessLayer.Один будет содержать открытые интерфейсы / классы, которые могут использоваться вашими модулями, а другой будет содержать фактическую реализацию уровня доступа к данным, например Entity Framework.

  • Если каждый модуль имеетэто собственная база данных или собственный набор объектов в базе данных (т. е. объекты Customer не существуют, если у вас не установлен клиентский модуль), тогда я бы реализовал IUnitOfWork в модулях, чтобы они обрабатывали свой собственный доступ к данным.У меня, вероятно, все еще есть некоторые общие интерфейсы в библиотеке Common, из которых можно собирать модули.

В идеале все ваши модули и ваш Shell могут получить доступ к Commonбиблиотека.Модули не должны иметь доступ друг к другу, если они не основаны на них.Например, модуль Customer Statistics, основанный на базовом модуле Customer, должен получить доступ к модулю Customer.

Если ваши ViewModels должны использовать UnitOfWork или Repository, я бы попросил их использовать Repository только.В идеале ваш Repository должен быть похож на черный ящик - ViewModels может получать / сохранять данные, используя Repository, но не должен знать, как это реализовано.Хранилища могут получать данные из службы, структуры сущностей, прямого доступа к данным или откуда-либо еще, и ViewModel не заботится.

Я не специалист по архитектуре проектирования, однако, как бы я ее построил:)

0 голосов
/ 20 апреля 2012

Я настоятельно рекомендую вам получить Введение в PRISM и Шаблон репозитория внутри Библиотека шаблонов проектирования обучающие видеоролики. Они замечательные. Надеюсь, это поможет

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...