Архитектура уровня представления в корпоративном приложении - PullRequest
1 голос
/ 10 апреля 2010

В нашей компании мы разрабатываем приложение, которое будет состоять из нескольких модулей. Архитектура в значительной степени определена, но у меня есть мысли по поводу презентационного уровня, и мне бы очень хотелось услышать ваше мнение. Архитектура выглядит следующим образом:

Модуль Foreach. Мы создаем несколько пространств имен, и они будут скомпилированы в их собственной библиотеке классов. Поэтому для нашего модуля CRM мы создаем следующее:

  • ProductName.CRM.ServiceLayer (содержит интерфейсы сервисных контрактов модуля CRM)
  • ProductName.CRM.ServiceLayer.Implementation (реализует интерфейсы уровня обслуживания модуля CRM)
  • ProductName.CRM.BusinessLayer (содержит бизнес-компоненты модуля CRM)
  • ProductName.CRM.BusinessLayer.BusinessObjects (содержит бизнес-объекты модуля CRM)
  • ProductName.CRM.DataLayer (содержит интерфейсы DAO модуля CRM)
  • ProductName.CRM.DataLayer.SqlServer (реализует интерфейсы уровня данных модуля CRM)

Мы создаем ту же структуру библиотек классов для модулей Финансы, HRM, Снабжение и т. Д .:

  • ProductName.Finance ....
  • ProductName.HRM ....
  • и т.д.. Я думаю, что вы получите идею сейчас:)

Также мы подумали о «сквозных проблемах» и для этого создаем следующие пространства имен и библиотеки классов

  • ProductName.Framework.ExceptionHandling
  • ProductName.Framework.Logging
  • ProductName.Framework.Security
  • etcetra ...

Так вот какова наша архитектура, и в данный момент я пытаюсь найти правильный способ настройки PresentationLayer. Например, должен ли я создать модуль foreach для PresentationLayer-библиотеки (ProductName.CRM.PresentationLayer, ProductName.Finance.PresentationLayer и т. Д.). И создайте общую библиотеку ProductName.PresentationLayer, которая содержит ссылки на все остальные библиотеки Module.PresentationLayer. Этот общий ProductName.PresentationLayer будет иметь функциональность Login / MainForm и возможность запуска форм, которые реализованы в одном из модулей PresentationLayer. Это будет как точка входа приложения в другие модули.

Или ...

Должен ли я создать только одну библиотеку ProductName.Presentation, которая содержит все формы для всех модулей. Делая это, я могу легко переходить к другим формам и не беспокоиться о ссылках между модулями, когда они собираются использовать формы друг друга (иногда они будут делать).

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

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

спасибо заранее, Ура!

1 Ответ

1 голос
/ 10 апреля 2010

Вы всегда можете создавать интерфейсы, которые реализуют формы, если им нужно обмениваться данными. На самом деле, вероятно, не очень хорошая идея знать много форм друг о друге, так как это создает проблемы при обслуживании и улучшении в в долгосрочной перспективе.

Используя интерфейсы и, возможно, какой-то вид службы локатора, вы можете избежать жестких зависимостей между формами - и тогда вы можете свободно использовать любую архитектурную модель (1 большая сборка против многих более мелких).

...