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

Question

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

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

Answer 1

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

Answer 2

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

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

Википедии

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

Для архитектуры приложений отличная книга для начала - Domain Driven Design. Эрик Эванс подробно описывает различные слои приложения. Он также обсуждает базы данных импеданса и то, что он называет «Локальностью контекста»

Локальности Контекст

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

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

• Domain Driven Design Quickly
• Applying Domain Driven Design and Patterns
• Clean Code
• Working Effectively with Legacy Code
• Refactor

До того, как у меня была возможность испытать The Big Ball of Mud или Spaghetti Code Мне было трудно понять, почему Application Architecture так важна ...

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

Answer 3

Причина, по которой я видел эту тенденцию, заключается в том, что LINQ и LINQ to SQL ORM дают вам отличную альтернативу хранимым процедурам.

«Правильно» - это то, пользуетесь ли вы этим лично.

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Presentation Layer: .Net, PHP, независимо от

Business Layer: хранимые процедуры

данных слоя: хранимые процедуры или DML

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

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

(я ожидаю получить кругло вспыхнуло за эту ересь!)

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

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

Answer 11

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

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

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

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