лучший способ ссылки на бизнес-объекты из уровня представления ..? - PullRequest
Новая
       47

лучший способ ссылки на бизнес-объекты из уровня представления ..?

2 голосов
/ 30 марта 2010

Я хочу разработать корпоративное приложение, которое включает уровень представления WindowsForms, компоненты среднего уровня для бизнес-логики и доступа к данным, а также базу данных MsSQL Server. Компоненты среднего уровня должны содержать некоторые бизнес-объекты и будут вызываться из уровня представления с использованием .NET Remoting. Какой лучший способ (и почему) ссылаться на эти бизнес-объекты из уровня представления?

  • А) Создать проект библиотеки классов, реализующий бизнес-объекты. Ссылка на этот проект из уровня представления и среднего уровня.
  • B) Создать интерфейсную библиотеку проекта, определяющую бизнес-объекты. Создать проект библиотеки классов, реализующий интерфейсы. Проект библиотеки эталонных классов из среднего уровня. Эталонный интерфейс библиотеки проекта из уровня представления.
  • C) Создание отдельных проектов библиотеки классов для среднего уровня и уровня представления. Ссылка на соответствующий проект из уровня представления.

Ответы [ 2 ]

2 голосов
/ 30 марта 2010

Я видел, как все три подхода работают хорошо.

Что иногда может быть хорошо, так это начать с A, затем, когда сложность возрастает, перейти к B, затем C.

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

Возможно, вы захотите пересмотреть использование .NET Remoting - WCF, безусловно, является лучшей технологией и намного проще в использовании.

2 голосов
/ 30 марта 2010

Вероятно, нет однозначного и однозначного ответа на это, это зависит от того, что вы делаете.

  • A часто будет достаточно хорошим во многих случаях. Для небольших проектов с «одним приложением» на самом деле нет никаких причин, по которым вы не можете просто ссылаться на библиотеку бизнес-объектов непосредственно из слоев пользовательского интерфейса и BL. Это, конечно, самое простое, а иногда и простота лучше всего.

  • B , вероятно, «лучший», вы будете абстрагироваться от ваших реальных реализаций, так что будущие изменения возможны без разрыва контрактов, а модульное тестирование будет проще, если у вас есть интерфейсы. Другим преимуществом этого является то, что вам не будет слишком сложно переключаться с B на C в будущем, если вы сочтете это необходимым.

  • C , вероятно, излишне в большинстве случаев. Тем не менее, на более крупных проектах вы можете найти это необходимым. Я работал над большими n-уровневыми приложениями клиент-сервер, которые имели до трех независимых наборов объектов данных. Один набор используется в слое DA для отображения и хранения в базе данных. Второй набор в бизнес-логике и сетевых уровнях для обработки и передачи по сети, а третий набор в клиенте для привязки к пользовательскому интерфейсу. Также стоит рассмотреть возможность использования интерфейсов для C из-за преимуществ абстракции.

В целом, не зная точно область вашего приложения или область действия - B является хорошей отправной точкой.

...