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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 7

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

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

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

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

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

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

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

Answer 8

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

Answer 9

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