Маленькие методы - Маленькие ростки - PullRequest
0 голосов
/ 05 января 2011

Дядя Боб рекомендует использовать маленькие методы. Хранимые процедуры имеют идеальный размер? Или они могут работать на 100 и 100 строк?

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

Если вы читаете Адама Маханича, его смещение относится к базе данных, подразумевает ли это длительные хранимые процедуры, которые понимает только автор sproc, оставляя сопровождающим иметь дело с беспорядком?

Я полагаю, что есть два взаимосвязанных вопроса.

Заранее спасибо за ответ на нечеткий вопрос (ы).

Ответы [ 3 ]

2 голосов
/ 05 января 2011

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

1 голос
/ 05 января 2011

Я думаю, что хранимые процедуры в настоящее время НИКОГДА не должны использоваться на всей системе в качестве единственного метода доступа к базе данных.Это устаревшая архитектура, которая в долгосрочной перспективе дает гораздо больше проблем с обслуживанием, чем пользы.В настоящее время есть намного лучшие способы справиться с любым требованием доступа к данным.Лучше всего использовать хранимую процедуру в определенных редких случаях, когда вы хотите, чтобы одна, четко определенная и уникальная функция извлекала данные, которые, как вы знаете, будут использоваться таким же образом в других приложениях.Хранимая процедура позволит вам быть СУХИМ в этом случае.Также в некоторых случаях, когда администратор БД, который занимается защитой, должен защищать определенную часть данных (например, таблицу кредитных карт) таким детализированным способом, который разрешает доступ только к SP,

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

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

0 голосов
/ 05 января 2011

Я бы применил те же рекомендации к SP, насколько это возможно, так как я рассматриваю код SP.

Бизнес-логика, на мой взгляд, относится к уровню кодовой базы, а не к SP. Для меня, если ИП придерживаются бизнес-логики, они слишком много знают о том, что они должны делать. Я думаю, что SP в основном следует выполнять при использовании для извлечения данных и / или их хранения. Если бы бизнес-логика применялась в цепочке команд / в коде, то SP вызывались бы только тогда, когда бизнес-логика была удовлетворена.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...