Прежде всего, я бы немного упростил ваш список проектов до 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 не заботится.
Я не специалист по архитектуре проектирования, однако, как бы я ее построил:)