У меня есть веб-приложение, которое взаимодействует с SQL-сервером. Вместо жесткого кодирования всех строк запроса я решил сохранить их в глобальном файле ресурсов. Это считается плохой практикой?
На стороне примечания, когда я это делаю, Visual Studio кричит на меня о возможности SQL-инъекции, несмотря на то, что эти параметры задаются параметрами (не говоря уже о "орфографических" предупреждениях внутри файла ресурсов).
Практики попадают в диапазон (например, Избегайте, Предпочитают, Использовать и т.д.) и зависят от контекста.
Если у вас есть мандат от максимума, который хранится-procs не будет использоваться, и вы также не должны использовать ORM, то хранение вашего сложного SQL в качестве ресурса не так уж плохо из практики, потому что вы, по крайней мере, не имеете чтобы избежать символов в System.String, и вы по крайней мере сохраните его в безопасности от глаз. Если ваш SQL динамический по своей природе, объединение файлов ресурсов с механизмом шаблонирования текста довольно чисто.
Тем не менее, как правило, (в большинстве контекстов), следует избегать использования файлов ресурсов, если не будет очевидной выгоды в расходах на обслуживание, удобочитаемости и возможности. Существует довольно много чистых способов привязки хранимых процедур к коду; существует ряд компетентных инструментов ORM и слоев доступа к мини-данным, которые могли бы улучшить работу.
Наличие SQL-запросов, отделенных от кода приложения, является хорошей вещью. Хранимые процедуры - это нормальный способ сделать это, но если это невозможно и вам нужно напрямую использовать SQL, я думаю, что ваш подход хорош. При использовании последних версий SQL Server параметризованные запросы предварительно скомпилированы при первом запуске и дают аналогичную производительность SP.
Я бы посоветовал вам изучить другие методы доступа к данным, такие как linq-to-sql, который автоматизирует генерацию запросов SQL и дает вам более чистый интерфейс в коде.
Файлы ресурсов определенно не для этого. Точка файлов ресурсов должна быть централизованным хранилищем для вещей, которые могут быть локализованы (т.е. Переопределены другими файлами ресурсов, которые определены для других языков/культур).
Например, вы поместите строку "Hello" в X.resources.dll, но затем вы также можете создать es-ES\X.resources.dll для испанского языка, в котором строка будет указывать "Hola" вместо — то, когда ваше приложение запрашивает строку, оно получит любую версию, соответствующую языку/культуре конфигурации операционной системы пользователя.
Если вы хотите, чтобы ваш SQL был легко изменен без перекомпиляции кода, поместите его в свой App.config и используйте класс ConfigurationManager для его чтения. Если вы не хотите, чтобы он был изменчивым без перекомпиляции кода, просто скопируйте его как static/const string. Тем не менее, идеальным, конечно же, является создание реальных хранимых процедур.
Я думаю, что многие считают жесткий SQL-код плохой практикой, независимо от того, как он хранится...: -)
Я собираюсь предположить, что есть некоторая веская причина не использовать Linq для SQL, или Entity Framework, или другой инструмент ORM?
Если вы должны использовать жестко закодированный SQL в своем приложении, будет утверждать, что он является BETTER встроенным в ваш код, потому что он делает ваш код более удобочитаемым и, следовательно, более удобным для обслуживания...
Я не вижу ничего особенно "плохого" в этом. Это действительно не сильно отличается от жесткого кодирования кода sql внутри вашего кода и только незначительно отличается от генерации SQL ad-hoc во время выполнения.
Вы говорите, что используете параметризованные запросы, поэтому вам не нужно беспокоиться о введении script.
Если вы храните sql в файле ресурсов, чтобы придерживаться принципа DRY, тогда вместо этого вы можете использовать какой-то DAL для этой цели. Подобно Entity Framework (EF) или Linq-to-SQL
Я создал приложение с использованием этого шаблона - в PHP, а не .NET, но принципы одинаковы.
Преимущества:
Недостатки:
По моему опыту, преимущества не сочетаются с недостатками.
BTW - многие из этих недостатков также применимы к хранимым процедурам. Там хороший пример использования хранимых процедур - но там одинаково хороший случай для их не использования.
Это не обязательно плохая практика, но это затрудняет чтение вашей программы, если нужно открыть другой файл и найти правильный ключ.
Visual Studio жалуется, потому что не может видеть, что значение является постоянным и что оно всегда исходит от надежного источника.
Наличие SQL в исходных файлах не более "жесткое кодирование", чем остальная часть кода программы в исходных файлах. Почему вы это делаете в первую очередь? Повторное использование запросов? Возможно, вам стоит рассмотреть процедуры хранения...
То, что приходит на ум, состоит в том, что это просто добавляет ненужные сложности в код.
Да, вы могли бы сохранить запросы в файле ресурсов. Или, чтобы гарантировать, что никто не будет с ними общаться после развертывания проекта, вы можете зашифровать их и сохранить в файле. Или еще лучше, вы можете зашифровать их, а затем сохранить их в базе данных, чтобы никто, у кого не было доступа к машине, не мог с ними связаться.
Но в конце концов, я должен спросить, какой смысл? Просто скопируйте их и сделайте с ним.
ПОЦЕЛУЙ.
вы можете писать процедуры хранения и вызывать их в своем коде, а не читать запросы, хранящиеся где-то снаружи.