Должен ли уровень доступа к данным содержать бизнес-логику?

Question

Я видел тенденцию вывести бизнес-логику из уровня доступа к данным (хранимые процедуры, LINQ и т. Д.) В слой компонентов бизнес-логики (например, объекты C #).

Считается ли это "правильным" способом делать вещи в наши дни? Если это так, означает ли это, что некоторые позиции разработчиков баз данных могут быть исключены в пользу более средних позиций кодирования? (то есть больше кода на C #, а не более длинных хранимых процедур.)

Answer 1

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

Перемещение проблем на общий слой или также известный как Разделение проблем , существует уже некоторое время:

Wikipedia

Термин разделение интересов был вероятно, придумал Эдсгер В. Дейкстра в своей работе 1974 года "О роли научная мысль " 1 .

Для Архитектуры Приложений хорошей книгой для начала является Проектирование, управляемое доменом . Эрик Эванс подробно разбирает различные слои приложения. Он также обсуждает импеданс базы данных и то, что он называет «ограниченным контекстом»

Ограниченный контекст

Блог - это система, которая отображает сообщения от самых новых до самых старых, чтобы люди могли оставлять комментарии. Некоторые рассматривают это как одну систему или один «ограниченный контекст». Если вы подписываетесь на DDD, можно сказать, что в блоге есть две или две «ограниченные контексты»: система комментирования и система публикации. DDD утверждает, что каждая система является независимой (конечно, между ними будет взаимодействие) и должна быть смоделирована как таковая. DDD дает конкретные рекомендации о том, как разделить проблемы на соответствующие уровни.

Другие ресурсы, которые могут вас заинтересовать:

• Быстро управляемый доменом
• Применение управляемой доменом разработки и Узоры
• Чистый код
• Эффективная работа с Legacy Код
• Рефакторинг

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

Правильный способ работы всегда будет зависеть от размера, требований к доступности и срока службы вашего приложения. Использовать хранимые процедуры или не использовать хранимые процедуры ... Такие инструменты, как nHibrnate и Linq to SQL, отлично подходят для небольших и средних проектов. Чтобы прояснить ситуацию, я никогда не использовал nHibranate или Linq To Sql в больших приложениях, но мне кажется, что приложение достигнет такого размера, когда на сервере базы данных потребуется выполнить оптимизацию с помощью представлений, хранимых процедур и т.д. поддерживать приложение в рабочем состоянии. Для этой работы понадобятся разработчики, обладающие навыками разработки и баз данных.

Answer 2

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

Answer 3

Разделение слоев не автоматически означает отсутствие использования хранимых процедур для бизнес-логики. Такое разделение одинаково возможно:

Уровень представления: .Net, PHP, что угодно

Бизнес-уровень: хранимые процедуры

Уровень данных: хранимые процедуры или DML

Это очень хорошо работает с Oracle, например, когда бизнес-уровень может быть реализован в пакетах в схеме, отличной от уровня данных (для обеспечения надлежащего разделения интересов).

Важным является разделение интересов, а не язык / технология, используемые на каждом уровне.

(Я ожидаю, что за эту ересь возмутимся!)

Answer 4

Если вы строите многоуровневую архитектуру, и эта архитектура содержит выделенный бизнес-уровень, то, конечно, вы должны поместить туда бизнес-логику. Однако вы можете спросить любых пяти дизайнеров / архитекторов / разработчиков, что такое «бизнес-логика», и получить шесть разных ответов . (Эй, я сам архитектор, поэтому я знаю все о «с одной стороны, но с другой»!). Навигация по графу объектов является частью уровня данных или бизнес-уровня? Зависит от того, какие шаблоны EAA вы используете, и от того, насколько сложны / умны ваши доменные объекты. Или это, возможно, даже часть вашей презентации?

Но в более конкретном плане: инструменты разработки баз данных, как правило, отстают от Eclipse / Visual Studio / Netbeans /; и хранимые процедуры никогда не были чрезвычайно удобны для крупномасштабной разработки. Да, конечно, вы можете кодировать все на TSQL, PL / SQL и т. Д., Но за это придется платить. Более того, цена использования нескольких языков и платформ в одном решении увеличивает затраты на обслуживание и задержки. С другой стороны, перемещение доступа к данным вне досягаемости администраторов баз данных может вызвать другие головные боли, особенно в средах с общей инфраструктурой с любыми требованиями к доступности. Но в целом, да, современные инструменты и языки в настоящее время переносят логику с уровня данных (базы) на уровень приложений. Мы должны увидеть, насколько хорошо это работает и масштабируется.

Answer 5

Это действительно зависит от требований. В любом случае, пока он НЕ"за кнопкой", как это было. Я думаю, что хранимые процедуры лучше подходят для «классических» клиент-серверных приложений с меняющимися потребностями. Слой со средним уровнем «бизнес-логики» лучше подходит для приложений, которые должны быть очень масштабируемыми, работать на нескольких платформах баз данных и т. Д.

Answer 6

Идеального мира не существует. Речь идет об элегантности и о том, что работает лучше. Выполнение сложных SQL-запросов в слоях доступа к данным намного эффективнее, чем создание службы, которая запрашивает данные много раз, а затем объединяет и преобразовывает их. Когда вы делаете сложные запросы, вы помещаете бизнес-логику в эти запросы.

Answer 7

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

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

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

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

Answer 8

Бизнес-логика на уровне данных была распространена в клиент-серверных приложениях, так как на самом деле не было уровня бизнес-логики как такового (если вы действительно не могли серьезно препятствовать подключению кого-либо к базе данных вне приложения). ). Теперь, когда веб-приложения стали более распространенными, вы видите больше 3- и 4-уровневых приложений (клиент + веб-сервер + сервер приложений + сервер базы данных), и все больше компаний следуют передовым практикам и консолидируют бизнес-логику на своем собственном уровне. Я не думаю, что для разработчиков баз данных будет меньше работы, они, вероятно, просто станут теми, кто пишет уровень бизнес-логики (и позволит инструменту ORM писать большую часть уровня базы данных).

Answer 9

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

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

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

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

Answer 10

ВСЕГДА хорошая идея отделить ваши слои. Я не могу сказать вам, сколько раз я видел хранимые процедуры, которые ОЧЕНЬ мрачны из-за большого количества бизнес-логики, записанной в sproc. Кроме того, если по какой-либо причине вы измените сложную хранимую процедуру, у вас есть возможность сломать ВСЕ, что ее использует.

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