Sprawdzone procedury dotyczące zapytań SQL Inline

Question

Pracuję z witryną asp.net, która korzysta z wielu wbudowanych zapytań SQL ... i zastanawiam się, czy najlepiej jest utworzyć zapytania śródliniowe w locie:

int i = 500; 

    using (SqlConnection conn = new SqlConnection(connStr)) 
    { 
     SqlCommand com = new SqlCommand(conn); 
     ... 
     com.CommandText = "select from table where column < @parameter"; 
     ... 
    } 

Albo mieć klasę do przechowywania wszystkich zapytań potrzebnych do aplikacji. Coś takiego:

class SqlQueries 
{ 
    private string query1 = 
      "select * from tblEmployees where EmployeeName = @EmployeeName"; 

    private string query2 = 
      "select * from tblVacation where EmployeeName = @EmployeeName"; 

    public string Query(string s) 
    { 
     string str = string.Empty; 

      switch (s) 
      { 
       case "query1": 
        str = query1; 
        break; 
       case "query2": 
        str = query2; 
        break; 
      }  

    return str;  

    } 
} 

Dziękujemy!

Answer 1

Użyłem wielu zapytań ADO.NET w moich czasach i zawsze używałem pierwszej metody. Druga metoda to ciekawy pomysł, ale edytowanie tych zapytań może być uciążliwe, jeśli znajdujesz się w innym miejscu kodu, który z niego korzysta. Utrudnia to również sprawdzanie, co robi zapytanie w określonym miejscu kodu. Przykład:

string sql = "Update User set age = @age where UserId = @UserId"; 

mówi deweloper co się dzieje, gdy:

string sql = SqlQueries.Query("updateAge"); 

Liście pytania, co tabeli/kolumny są aktualizowane. Ponadto, z pierwszym, wiesz dokładnie, jakie parametry należy dodać.

Jeśli piszesz to zapytanie w kilku miejscach, które mogłyby zmienić rzeczy

Answer 2

Wydaje mi się, że zapytań "inline" można używać tak długo, jak długo nie są powtarzane w kilku miejscach. Jeśli to się zaczyna, możesz zacząć tworzyć klasy zapytań.

Answer 3

To nie jest straszne, aby umieścić literał bezpośrednio w metodzie, o ile zawsze wywołasz tę samą metodę za każdym razem, gdy chcesz uruchomić to zapytanie. Jeśli jednak zamierzasz skopiować literał ciągu znaków do wielu miejsc w kodzie, to zdecydowanie preferowana jest stała. Jednak zamiast brać łańcuch jako argument dla metody Query w twoim drugim przykładzie, powinna ona przyjąć wartość wyliczenia.

Jeśli jednak używasz drugiej metody, którą opisałeś, zapytałbym Cię, dlaczego nie używasz zamiast tego procedur przechowywanych?

Answer 4

W obu przypadkach jesteś ostatecznie budowę/pobierania String który będzie przechodzić do CommandText. Więc nie byłoby takiej różnicy. Jedyne, co musisz wziąć pod uwagę w swoim przypadku, to w jaki sposób zachowałbyś kod lub jak inni ludzie zrozumieją Twój kod.

Answer 5

Jeśli zamierzasz używać wbudowanego kodu SQL przynajmniej nie umieszczaj go w kodzie strony internetowej, ponieważ będzie to bolesne, gdy wprowadzisz zmiany w bazie danych, aby wiedzieć, na co ona wpływa. Umieszczenie wszystkich zapytań w jednej klasie może być nieco zdezorganizowane, ale jeśli zgrupujesz je według klas funkcjonalnych (takich jak klasy menedżerskie dla twoich obiektów biznesowych), łatwiej będzie sobie z nimi poradzić.

Answer 6

Zalecam stosowanie procedur przechowywanych jako o wiele lepszym rozwiązaniem problemu niż zapytania zakodowane w sztywnych kodach. Jeśli musisz zmienić zapytanie w późniejszym terminie, nie musisz przebudowywać aplikacji, więc błędy w zapytaniu mogą zostać naprawione bez potrzeby wdrażania całej aplikacji. Druga opcja, którą tam masz, to koszmar utrzymania czekający na spełnienie. Wszystko wygląda tak ładnie, gdy masz jedno lub dwa pytania, ale zaczyna to wyglądać nieco bardziej brzydko, gdy masz tam dziesiątki lub setki.Kod wygląda to C#, więc polecam sprawdzić na Microsoft Enterprise Library,

http://msdn.microsoft.com/en-us/library/ff632023.aspx

Być może trzeba pobrać inną wersję w zależności od wersji .NET framework jesteś rozwijających się.

Answer 7

Jeśli koniecznie mieć „inline” SQL, w przeciwieństwie do procedur składowanych (i zrobiłem to dla zastosowań typu narzędzie, które jedynie oddziałują z bazą danych, zamiast własnym IT), proponuję wprowadzenie twój SQL do embedded resource file. Ułatwi to utrzymanie twoich zapytań (chociaż będziesz musiał ponownie skompilować swoją aplikację, aby wprowadzić zmiany).

Answer 8

Jeśli zapytania są dłuższe niż jeden lub dwa wiersze, należy rozważyć umieszczenie ich w osobnym pliku .sql. Ustaw akcję budowania na pliku na zasób osadzony i uzyskaj do niego dostęp za pomocą wywołania metody GetManifestResourceStream(). W ten sposób podnosisz sql do statusu właściwego języka, z podświetlaniem składni, sprawdzaniem poprawności i intellisense (po podłączeniu VS do twojego DB). Nie trzeba dodawać, że to znacznie ułatwia konserwację.

Jeśli wszystko to wydaje się kłopotliwe, chwyć moje rozszerzenie VS, QueryFirst. Utwórz pliki .sql za pomocą dostarczonego szablonu i zostaną one automatycznie podłączone do kompilacji. Ale nie będziesz się tym przejmował, ponieważ uzyskasz dostęp do zapytań za pośrednictwem wygenerowanych klas.

Sql jest jedynym językiem komputerowym, jaki mogę sobie wyobrazić, który akceptujemy, gdy widzi się go w literałach ciągów. To powinien być skandal.