Это плохая практика для хранения запросов SQL в файле ресурсов?

Question

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

В дополнение к этому, когда я это делаю, Visual Studio кричит мне о возможности внедрения SQL, несмотря на то, что эти запросы параметризованы (не говоря уже о предупреждениях "орфографии" внутрифайл ресурсов).

Answer 1

Практики попадают в диапазон (например, Избегайте , Предпочитайте , Используйте и т. Д.) И зависят от контекста.

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

Тем не менее, обычно (то есть кажется в большинстве случаев) с использованием файлов ресурсов следует избегатьесли нет явного преимущества в затратах на обслуживание, удобочитаемости и возможностях.Существует довольно много простых способов привязать хранимые процедуры к коду;Есть ряд компетентных инструментов ORM и слоев мини-доступа к данным, которые могли бы работать лучше.

Answer 2

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

Однако я бы посоветовал вам изучить другие методы доступа к данным, такие как linq-to-sqlавтоматизирует генерацию SQL-запросов и обеспечивает более понятный интерфейс в коде.

Answer 3

Файлы ресурсов определенно не место для этого. Смысл файлов ресурсов состоит в том, чтобы быть централизованным репозиторием для вещей, которые могут быть локализованы (то есть переопределены другими файлами ресурсов, которые определены для других языков / культур).

Например, вы бы поместили строку "Hello" в X.resources.dll, но затем вы могли бы также создать es-ES\X.resources.dll для испанского языка, в котором вместо строки указывалось бы "Hola" & mdash; затем, когда ваше приложение запросит строку, оно получит любую версию, соответствующую языку / культуре конфигурации операционной системы пользователя.

Если вы хотите, чтобы ваш SQL легко изменялся без перекомпиляции кода, поместите его в App.config и используйте класс ConfigurationManager для его считывания. Если вы не хотите, чтобы это можно было изменять без перекомпиляции кода, просто закодируйте код как 1011 * / const string. Тем не менее, в идеале, конечно, нужно создавать реальные хранимые процедуры.

Answer 4

Я создал приложение, используя этот шаблон - на PHP, а не .Net, но принципы те же.

Преимущества:

• Я мог бы легко найти весь необходимый мне SQL в одном файле. Это помогло при работе с вопросами базы данных (действительно ли какая-либо часть приложения использует эту таблицу? Сколько запросов у нас есть в этой таблице обновлений z?).
• Я мог бы легко обновить SQL без изменения остальной части кода.

Недостатки:

• Это затрудняло отладку остальной части кода - если возникла проблема с данными, возвращаемыми из базы данных, мне пришлось искать в двух местах. И многие из ключей ресурсов были очень похожи, что привело к некоторым интересным моментам.
• На практике я никогда не обновлял SQL без изменения остальной части кода.

По моему опыту, преимущества не сочетаются с недостатками.

Кстати, многие из этих недостатков также относятся к хранимым процедурам. Есть хороший пример использования хранимых процедур - но есть и хороший пример, когда они не используются.

Answer 5

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

Я собираюсь предположить, что есть некая убедительная причина не использовать Linq to SQL, или Entity Framework, или другой инструмент ORM?

Если вы должны использовать жестко закодированный SQL в своем приложении, вы можете утверждать, что он является ЛУЧШЕ встроенным в вашем коде, потому что он делает ваш код более читабельным и, следовательно, более легким в обслуживании ...

Answer 6

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

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

Если вы храните sql в файле ресурсов, чтобы придерживаться принципа СУХОЙ, то вы можете вместо этого использовать какой-то DAL для этой цели.Как Entity Framework (EF) или Linq-to-SQL

Answer 7

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

Visual Studio жалуется, потому что не может видеть, что значение является постоянными что он всегда исходит из надежного источника.

Наличие SQL в исходных файлах не более "жесткое кодирование", чем оставшаяся часть программного кода в исходных файлах.Почему вы делаете это в первую очередь?Чтобы повторно использовать запросы?Может быть, вы должны рассмотреть процедуры магазина вместо ...

Answer 8

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

Answer 9

На ум приходит то, что это просто добавляет ненужные сложности в код.

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

Но в конце концов, я должен спросить, какой смысл? Просто жестко закодируйте их и покончите с этим.

ПОЦЕЛУЙ.