Призма модульности практики - PullRequest
Новая
       22

Призма модульности практики

1 голос
/ 24 ноября 2011

Я изучаю Prism и мне нужно создать небольшое демонстрационное приложение.У меня есть несколько вопросов дизайна.Различия в отношениях могут быть небольшими, но позже мне нужно применить методы к крупномасштабному проекту, поэтому я стараюсь думать о будущем.

  1. Принимая во внимание классический сценарий, связанный с БД - мне нужно получить список сотрудников, и двойной щелчок по элементу списка получает дополнительную информацию для этого сотрудника: если проект доступа к данным будет модулемИли проект, доступ к которому осуществляется через шаблон хранилища, является лучшим решением?Как насчет крупномасштабного проекта, когда БД представляет собой более одной таблицы и предоставляет, скажем, информацию о сотрудниках, продажах, компаниях и т. Д.?

  2. В настоящее время я рассматриваю возможность использования модуля DataAccess в качестве отдельного модуля и определил его интерфейс в проекте инфраструктуры, а также тип его возврата (EmployeeInformation),Это означает, что и мой DataAccess модуль, и мое приложение должны ссылаться на проект Infrastructure.Это хороший путь?

  3. Я получаю доступ к указанному модулю DataAccess, используя ServiceLocator (MEF) из моего приложения.Должен ли ServiceLocator быть доступен частям приложения или он предназначен для использования только в разделе инициализации?

Спасибо.

1 Ответ

1 голос
/ 24 ноября 2011
  1. Модуль необходим и имеет смысл, когда он содержит часть приложения, которая может жить самостоятельно. Это могут быть части приложения, которые могут использовать только несколько человек, например доступ к модулю управления пользователями разрешен только администраторам. Но ваш уровень доступа к данным - это не та отдельная функциональность, которая обычно входит в модуль. Лучше поместить его в общую сборку, которую могут использовать реальные модули. Проблема здесь заключается в том, что все модули зависят от этой сборки DAL, поэтому при проектировании приложения имейте в виду задачу обновления DAL (нисходящая совместимость).
  2. Обычно нет проблем с тем, чтобы широко используемые типы находились в общей сборке. Но это не сборка инфраструктуры. Инфраструктура, как следует из этого слова, предоставляет услуги для совместной работы модулей. Ваши общие типы должны входить во что-то вроде YourNamespace.Types или YourNamespace.Client.Base или ...
  3. Эта тема во многих аргументах и ​​до сих пор неясна (по крайней мере, с моей точки зрения). Purists of Dependency Injection говорят, что его следует использовать только во время инициализации. Прагматики используют ServiceLocator во всем приложении.
...