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

Question

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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