Кто из вас занимается 3-х уровневым дизайном?

Question

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

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

Я предпочитаю почти полностью перенести уровень данных в базу данных с помощью хранимых процедур и просто иметь очень легкий уровень данных в коде, который переносит вызовы sproc в бизнес-объекты.

Как вы к этому подходите?

РЕДАКТИРОВАТЬ: Если все, что вы собираетесь сделать, это определить, что такое 3-уровневый, не тратьте свое время на ответы. Я ищу, как конкретные люди реализовали это, использовали ли вы хранимые процедуры или ORM, как вы справились с циклическими зависимостями между DAL и BLL? Theres много глубины к этой теме, кроме высказывания

• UI
• Бизнес
• Данные

Answer 1

Некоторое время назад я занимался веб-приложениями, а также следил за 3-уровневым:

Пользовательский интерфейс: чистые страницы ASPX. На самом деле иногда бывает сложно оттолкнуть отсюда свой бизнес-уровень, потому что здесь можно быстро выполнить вычисления или что-то вроде этого. Тем не менее, я достаточно дисциплинирован, чтобы убедиться, что код на страницах ничего не делает, только показывает / скрывает панели, обновляет пользовательский ввод и т. Д.

DAL: все данные слоя доступа к данным. Мне очень понравилось использовать доступные классы XSD / DataTable / TableAdapter. Я также использую методы CRUD на основе хранимых процедур, поэтому подключить адаптеры к хранимым процессам очень просто.

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

Answer 2

Еще одно замечание: никогда не забывайте, что n-уровневое разбиение является логическим, а не физическим разделением процессов. Т.е. не должно быть необходимости, чтобы бизнес-логика выполнялась в другом процессе (или в другом блоке), чем код представления. Важным является поддержание чистоты кода.

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

Answer 3

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

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

Answer 4

3-х уровневая:

• База данных работает как хранилище данных, мы также устанавливаем зависимости в базе данных
• C # бизнес-уровень - занимается принятием пользовательского запроса, отправленного через http (полученного страницей aspx), сбором правильного ответа на основе состояния базы данных и возвратом его клиенту через xml (хотя я бы рекомендовал json)
• javascript front end - занимается рендерингом xml в удобной для пользователя форме.

Answer 5

Я обнаружил, что 2,5-уровневый дизайн лучше всего работает для новых веб-приложений, которые я создал. Я обычно начинаю с 2 библиотек классов и 1 веб-приложения.

• Company.Data (Библиотека классов)
• Company.Web (библиотека классов) (содержит PageBase, пользовательские элементы управления, вспомогательные функции и т. Д.)
• Company.Web.WebApplication (веб-приложение)

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

Company.Data

Эта сборка состоит в основном из классов и коллекций данных сущностей. Например, у меня обычно есть таблица с именем Settings в моих веб-приложениях. Будет создан класс Setting и SettingCollection.

Так что, если мне нужно загрузить определенную настройку, я могу сделать это ..

Dim setting As New Setting(1) 'pass in the id of the specific setting
setting.Value = "False" 'change the value
setting.Save() ' Call the save method to persist changes back to the database

или для создания новой настройки я просто не передаю значение в конструктор

Dim setting as New Setting()
setting.Name = "SmtpServer"
setting.Value = "localhost"

setting.Save()

Мои пространства имен в сборке Company.Data обычно выглядят так ...

Company.Data.Entites
Company.Data.Collections
Company.Data.BusinessObjects

(Это пространство имен используется для создания пользовательских методов доступа к данным)

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

Например, столбец имени в таблице настроек имеет уникальный индекс. Общий метод с именем GetSettingByName будет сгенерирован автоматически, и он вернет объект настройки. Этот метод будет в Company.Data.BusinessObjects пространстве имен

Для классов сущностей и бизнес-объектов создаются два файла. 1, который генерируется каждый раз, и 1, который редактируется и генерируется только первый раз. Я использую частичные классы, чтобы позволить мне добавлять пользовательский код без перезаписи.

Для меня эта методология сработала очень хорошо. Генерация кодесмитов экономит мне бесчисленные часы кодирования. Я могу добавить 5 новых столбцов в таблицу, восстановить весь новый код в секундах. Хранимые процедуры будут удалены и воссозданы.

2.5-уровневый дизайн работает хорошо, потому что мое приложение будет использовать только одну базу данных, а это Sql Server. Необходимость использовать access, oracle, mysql в будущем не произойдет.

Answer 6

Мы используем 6-уровневый дизайн.

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

• HTML-представление на стороне сервера. Это частично обусловлено бизнес-правилами. Но в используемом нами языке шаблонов нет обработки.

• Функции просмотра на стороне сервера, бизнес-логика, «контроль». Здесь происходит навигация, валидация и прикладная обработка «более высокого уровня». Здесь происходит изменение состояния - все вычисляется, обновляется, удаляется и т. Д. Это обработка. Здесь применяются аутентификация и авторизация.

• Определения модели (с использованием слоя ORM). Это объектная модель. Он сопоставляется с реляционной моделью. Он включает всю обработку на уровне модели как методы объекта. Здесь выполняются некоторые вычисления, здесь определяются фильтрация, подсчет, упорядочение. Это наш полезный взгляд на данные.

• Уровень доступа (своего рода подключение к базе данных). Зависит от базы данных товара. Он управляется слоем ORM, поэтому мы не делаем никакого кодирования, просто настраиваем.

• Постоянное хранение в БД (без хранимых процедур, без триггеров).

Answer 7

DI заменил уровни для меня. Да, вы все еще можете логически сортировать поставщиков по уровням, но различия между уровнем логики и уровнем базы данных были размыты из-за других проблем проектирования, ИМХО Если вы не уверены, что я имею в виду, посмотрите «анемическую модель» войны.

Answer 8

n-ярусный дизайн

Я думаю, что расслоение работает довольно хорошо. Взгляните на уровни в модели OSI. Я использовал три уровня, которые вы описали, и этот подход действительно помог. Абстракция Model View Controller часто полезна в больших настольных приложениях. Вы можете продолжать разбивать вещи на более мелкие и более управляемые части. Есть точка убывающей отдачи. И бывают случаи, когда мы хотим удалить уровни абстракции и, возможно, поговорить напрямую с оборудованием - это зависит от целей вашего приложения.

Answer 9

Мы однажды подошли к нему, используя следующее: - Уровень пользовательского интерфейса (где весь пользовательский интерфейс) - Бизнес-уровень (где вся бизнес-логика) - Уровень данных (где весь доступ к БД)