Przechowywanie zapytań SQL w pliku konfiguracyjnym?

Question

Ogólne pytanie na temat tego, co wszyscy sądzą o przechowywaniu zapytań SQL w pliku konfiguracyjnym?

Czy to tylko kolejna szopa na rowery?

Cheers, Ben

Answer 1

To, co można zrobić, jeśli uzywasz iBatis. Nie widzę w tym szkody.

Z pewnością bije je dynamicznie, gdy jest to niepotrzebne.

Answer 2

Nie. Nigdy. Poważnie;) Sprzątam to tutaj w tej chwili.

Spróbuj spojrzeć na BLToolkit - przechowuje je w atrybutach bezpośrednio na klasie abstrakcyjnej, dynamicznie generując cały dostęp do kodu pod. To samo, co użycie go w pliku konfiguracyjnym, ale bez pisania lub oglądania głupiego kodu DAL.

Answer 3

Nie brzmi to tak źle, pod warunkiem, że spełnia wymagania.

Czy próbujesz zezwolić klientowi na przeglądanie i edycję zapytań?

Czy próbujesz ułatwić rozwój/testowanie?

Oczywiście wolę to umieszczanie zapytań w kodzie.

Istnieje jednak ryzyko, że plik ten zostanie powiększony o niezliczoną liczbę nieco innych zapytań (SORT ASCENDING, SORT DESCENDING, SUMA (col1) + SUMA (col2), SUMA (col1) + SUMA (col3) itd.)

Answer 4

w tym przypadku, to bym je przechowywać w db:

1. Czy utrudnić regularne Joe pobawić wokół moich zapytań i zagrozić mojej aplikacji.
2. Nie można wywnioskować, w jaki sposób przechowuję moje dane.
3. Zmiany zostaną odzwierciedlone automatycznie, bez konieczności "wypychania" pliku konfiguracyjnego.

Ale tak naprawdę, ekstrapoluję, nie znając rzeczywistego scenariusza. Ale poza mankietem nie chciałbym, aby inni widzieli, jak wchodzę w interakcje z moim schematem lub w jaki sposób jest on układany.

Answer 5

Jakie jest twoje uzasadnienie umieszczenia ich w dowolnym miejscu, ale w kodzie? Zauważyłem, że częściej niż SQL zmienia się w tym samym tempie, co kod, co oznacza, że ​​jeśli zmienisz UserDao.java, prawdopodobnie będziesz musiał zmienić sql -statements.properties w tym samym czasie. W związku z tym kod jest czytany wiele razy więcej niż jest napisane, więc pisanie czytelnego kodu ma kluczowe znaczenie w czystym kodzie. Z instrukcjami SQL w oddzielnym pliku, programista musi szukać gdzie indziej, aby dowiedzieć się, jakiego zapytania używa twój UserDao, utrudniając zrozumienie twojego kodu.

Krótka odpowiedź? Unikałbym go, jeśli to możliwe.