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

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

то, Что является "правильным", - извлекаете ли Вы выгоду из выполнения этого лично.

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

Уровень представления: .NET, PHP, безотносительно

Бизнес-Слой: Хранимые процедуры

Слой Данных: Хранимые процедуры или DML

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

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

(я ожидаю резко гореться для этой ереси!)

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

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

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

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

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

Википедия

термин разделение проблем был, вероятно, введен Edsger W. Dijkstra в его статье 1974 года "На роли научной мысли" 1 .

Для Архитектуры приложения замечательная книга для запуска с Доменный Управляемый Дизайн . Eric Evans ломает различные слои приложения подробно. Он также обсуждает импеданс базы данных и что он называет "Ограниченным Контекстом"

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

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

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

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

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

правильный способ сделать вещи будут всегда, чтобы зависеть от размера, требований доступности и продолжительности жизни Вашего приложения. Использовать сохраненный procs или не использовать сохраненный procs... Инструменты, такие как nHibrnate и Linq к SQL являются большими для маленького к проектам среднего размера. Чтобы ясно выразиться, я никогда не использовал nHibranate или Linq К Sql на крупном приложении, но мое инстинктивное чувство является приложением, достигнет размера, где оптимизация должна будет быть сделана на сервере базы данных через представления, Хранимые процедуры.. и т.д. сохранять приложение производительным. Чтобы сделать эту работу, Разработчики и с навыками Разработки и с Базы данных будут необходимы.

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

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

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

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

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

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

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

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