Хранить запросы SQL в файле конфигурации?

Question

Общий вопрос о том, каково мнение каждого относительно хранения запросов SQL в файле конфигурации?

Это просто очередной велосипедный сарай?

Ура, Бен

Answer 1

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

Вы пытаетесь разрешить клиенту просматривать и редактировать запросы?

Вы пытаетесь облегчить разработку / тестирование?

Я, конечно, предпочитаю это встраивать запросы в код.

Но есть риск, что этот файл будет раздуваться с множеством слегка отличающихся запросов (SORT ASCENDING, SORT DESCENDING, SUM (col1) + SUM (col2), SUM (col1) + SUM (col3) и т. Д.)

Answer 2

Что вы думаете о размещении их где-нибудь, кроме кода? Я обнаружил, что чаще всего SQL меняется с той же скоростью, что и ваш код, что означает, что если вы измените UserDao.java, вам, вероятно, придется изменить sql-statements.properties одновременно. С учетом вышесказанного, код читается намного чаще, чем пишется, поэтому написание читаемого кода имеет решающее значение в чистой кодовой базе. С операторами SQL в отдельном файле разработчик должен искать в другом месте, чтобы выяснить, какой запрос использует ваш UserDao, что затрудняет понимание вашего кода.

Краткий ответ? Я бы избежал этого, если это возможно.

Answer 3

В этом случае я бы сохранил их в БД:

1. Было бы трудно обычному Джо возиться с моими запросами и ставить под угрозу мое приложение.
2. Они не могут определить, как я храню свои данные.
3. Изменения будут отражены автоматически, без необходимости «проталкивать» файл конфигурации.

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

Answer 4

Нет. никогда. Серьезно;) Убираюсь, что здесь на данный момент.

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

Answer 5

Это то, что вы бы сделали, если бы использовали iBatis. Я не вижу в этом вреда.

Конечно, это лучше, чем создавать их динамически, когда в этом нет необходимости.