Я видел тенденцию перемещать бизнес-логику из уровня доступа к данным (хранимые процедуры, LINQ и т.д.) и в компонентный уровень бизнес-логики (например, объекты С#).
Считается ли это правильным способом делать что-то в наши дни? Если да, значит ли это, что некоторые позиции разработчиков баз данных могут быть устранены в пользу более ранжированных позиций среднего уровня? (то есть больше кода С#, а не более длинных хранимых процедур.)
Логика доступа к данным принадлежит уровню доступа к данным, бизнес-логика принадлежит бизнес-уровню. Я не вижу, как смешивание двух из них может считаться хорошей идеей с точки зрения дизайна.
Если приложения небольшие с коротким сроком службы, то не стоит тратить время на абстрагирование проблем в слоях. В более крупных, долговечных приложениях логические/бизнес-правила не должны быть связаны с доступом к данным. Это создает кошмар обслуживания, когда приложение растет.
Перемещение проблем на общий уровень или также называется Разделение проблем, было какое-то время:
Википедия
Термин разделение проблем вероятно, придумал Эдсгер У. Дейкстра в своей статье 1974 года "О роли научная мысль" 1.
Для архитектуры приложений отличная книга, которая начинается с Domain Driven Design. Эрик Эванс подробно описывает различные слои приложения. Он также обсуждает импеданс базы данных и то, что он называет "ограниченным контекстом"
Ограниченный контекст
Блог - это система, которая отображает сообщения от самых новых до самых старых, чтобы люди могли комментировать. Некоторые будут рассматривать это как одну систему или один "ограниченный контекст". Если вы подписаны на DDD, можно сказать, что в блоге есть две системы или два "ограниченных контекста": система комментариев и система публикации. DDD утверждает, что каждая система независима (конечно, будет взаимодействие между ними) и должна быть смоделирована как таковая. DDD дает конкретные рекомендации о том, как разделить проблемы на соответствующие слои.
Другие ресурсы, которые могут вас заинтересовать:
Пока у меня не было шанса испытать Большой шар грязи или Кодекс спагетти Мне было трудно понять, почему Application Architecture так важна...
Правильный способ делать вещи всегда будет зависеть от размера, требований доступности и продолжительности вашего приложения. Использовать хранимые procs или не использовать хранимые procs... Инструменты, такие как nHibrnate и Linq to SQL, отлично подходят для проектов малого и среднего размера. Чтобы я убедился, я никогда не использовал nHibranate или Linq To Sql для большого приложения, но мое чувство кишки - это приложение, которое достигнет размера, при котором оптимизации необходимо будет выполнять на сервере базы данных через представления, хранимые процедуры и т.д. чтобы приложение было выполнено. Для выполнения этой работы необходимы разработчики с навыками разработки и базы данных.
Разделение слоев не автоматически означает не использование хранимых процедур для бизнес-логики. Это разделение одинаково возможно:
Уровень презентации:.Net, PHP, любой
Бизнес-уровень: хранимые процедуры
Уровень данных: хранимые процедуры или DML
Это очень хорошо работает с Oracle, например, когда бизнес-уровень может быть реализован в пакетах в другой схеме из уровня данных (чтобы обеспечить надлежащее разделение проблем).
Важное значение имеет разделение проблем, а не язык/технология, используемые на каждом уровне.
(Я ожидаю, что вокруг этой ереси будет круто!)
Это действительно зависит от требований. В любом случае, пока он НЕ "за кнопкой". Я считаю, что хранимая процедура лучше подходит для "классических" клиентских серверных приложений с меняющимися потребностями. Строгий средний уровень "бизнес-логики" лучше подходит для приложений, которые должны быть очень масштабируемыми, работать на нескольких платформах баз данных и т.д.
Если вы строите многоуровневую архитектуру, а архитектура содержит выделенный бизнес-уровень, то, конечно, вы должны поставить там бизнес-логику. Тем не менее, вы можете спросить всех пяти дизайнеров/архитекторов/разработчиков, что на самом деле "бизнес-логика", и получите шесть ответы. (Эй, я сам архитектор, поэтому я знаю все о "с одной стороны, а с другой"!). Выполняет ли навигацию объектную часть части слоя данных или бизнес-уровня? Зависит от того, какие шаблоны EAA вы используете, и точно, насколько сложны/умны ваши объекты домена. Или это, возможно, даже часть вашей презентации?
Но более конкретно: инструменты разработки баз данных, как правило, отстают от Eclipse/Visual Studio/Netbeans/; и хранимые процедуры никогда не были чрезвычайно удобными для крупномасштабного развития. Да, конечно, вы можете кодировать все в TSQL, PL/SQL и c, но есть цена для оплаты. Более того, цена на несколько языков и платформ, участвующих в одном решении, увеличивает затраты на обслуживание и задержки. С другой стороны, перемещение доступа к данным из досягаемости DBA может вызвать другие головные боли, особенно в средах с общей инфраструктурой с любыми требованиями к доступности. Но в целом, да, современные инструменты и языки в настоящее время перемещают логику с уровня данных (базового) в прикладной уровень. Нам нужно будет понять, насколько хорошо это работает и масштабируется.
Причина, по которой я видел эту тенденцию, заключается в том, что LINQ и LINQ to SQL ORM предоставляют вам отличную альтернативу хранимым процедурам.
Какое "право" заключается в том, пользуетесь ли вы этим лично.
Да, бизнес-логика должна быть на уровне бизнес-логики. Для меня это самый большой недостаток использования процедур хранения для всего и, таким образом, перемещение некоторых бизнес-правил в db, я предпочитаю, чтобы эта логика в BLL содержала DLL только связь с db
ВСЕГДА хорошая идея отделить ваши слои. Я не могу сказать вам, сколько раз я видел хранимые процедуры, которые ОЧЕНЬ явственны из множества бизнес-логики, записанных в sproc. Также, если вы по какой-либо причине модифицируете сложную хранимую процедуру, у вас есть возможность разбить ВСЕ, что ее использует.
Наши разработчики в моей компании переходят на LINQ с EF и отбрасывают хранимую процедуру, если мы не нуждаемся в ней. LINQ и EF делают разделение наших слоев намного проще... когда EF не сложно. Но это еще одна напыщенная речь.:)
В уровне данных, вероятно, всегда будет некоторый уровень бизнес-логики. Сами данные представляют собой представление некоторой из этой логики. Например, первичные ключи часто создаются на основе правил бизнес-логики.
Например, если ваша система не позволит заказу иметь более одного клиента, является частью бизнес-логики, но она также присутствует (или должна быть) в слое данных.
Кроме того, некоторые виды бизнес-правил лучше всего подходят для самой базы данных по причинам эффективности. Обычно это хранимые процедуры и, следовательно, существуют в слое данных. Примером может быть триггер, который отключается, если клиент потратил более $X в год или если корабль отличается от счета-фактуры.
Многие из этих правил могут обрабатываться и на бизнес-уровне, но для них также необходим компонент уровня данных. Это зависит от того, где находится ваша обработка ошибок.
Бизнес-логика в слое данных была распространена в клиент-серверных приложениях, так как на самом деле не было ни одного уровня бизнес-логики (если бы вы не могли действительно серьезно помешать кому-либо подключиться к базе данных вне приложения). Теперь, когда веб-приложения более распространены, вы видите больше трех- и четырехуровневых приложений (клиент + веб-сервер + сервер приложений + сервер базы данных), а другие компании следуют передовым методам и консолидируют бизнес-логику в своем собственном уровне. Я не думаю, что для разработчиков баз данных будет меньше работать, они, вероятно, просто станут теми, кто пишет уровень бизнес-логики (и пусть инструмент ORM записывает большую часть уровня базы данных).
Существуют также технические причины/ограничения, которые необходимо учитывать при планировании, где можно создавать бизнес-правила.
В большинстве приложений LOB централизация и производительность заставляют разработчиков использовать базу данных в качестве основного бизнес-уровня, поэтому в некотором смысле DAL и BL смешиваются или унифицируются.
Типичным примером будет поле, которое вычисляет текущее местоположение предмета аренды, часть информации, которая должна быть доступна для одного или для многих перечисленных элементов, делая представление SQL с функцией, определяемой пользователем, самым мощным кандидатом для удерживайте правило.
Приведенный выше пример действителен, конечно, если предпочтение отдается конкретному дизайну базы данных и процессам, но я просто хочу отметить, что в реальном мире мы выбираем на основе технических ограничений и других принципов, чаще, чем мы делаем для организации наш код.