2012-10-05 47 views
8

Tôi đang làm việc với trang web asp.net sử dụng rất nhiều truy vấn SQL nội tuyến ... và tôi tự hỏi liệu tốt nhất là tạo truy vấn nội tuyến khi đang bay:Thực hành tốt nhất cho truy vấn SQL nội tuyến

int i = 500; 

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

Hoặc để có một lớp học chứa mọi truy vấn cần thiết cho ứng dụng. Một cái gì đó như thế này:

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;  

    } 
} 

Cảm ơn bạn!

+1

Nếu bạn quyết định sử dụng phương pháp tiếp cận số 2 thì tôi khuyên bạn nên tạo một từ điển được lập chỉ mục bởi các tên truy vấn chứa SQL. Sau đó, bạn có thể sử dụng trình khởi tạo từ điển để liệt kê tất cả truy vấn của mình theo cách gần giống như bảng trong mã nguồn của bạn. Cách tiếp cận hiện tại của bạn là tiết và dễ bị lỗi sao chép-dán (hiện tại có ít nhất một phương pháp đó sẽ được trình biên dịch phát hiện). 'Từ điển mới {{" query1 "," select * ... "}, {" query2 "," select * ... "}};' –

+0

Cảm ơn mọi người! Quá tệ Tôi không thể chọn nhiều câu trả lời: ( – user1481183

Trả lời

7

Tôi đã sử dụng nhiều truy vấn ADO.NET trong ngày và tôi luôn sử dụng phương pháp đầu tiên. Phương pháp thứ hai là một ý tưởng thú vị, nhưng nó có thể là cồng kềnh để chỉnh sửa các truy vấn đó nếu bạn ở một vị trí khác trong mã sử dụng nó. Nó cũng làm cho nó khó khăn hơn để xem những gì một truy vấn đang làm tại một nơi cụ thể trong mã. Ví dụ:

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

nói với một nhà phát triển những gì đang xảy ra, trong khi:

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

Lá câu hỏi về những gì bảng/cột đang được cập nhật. Ngoài ra, với một trong những đầu tiên, bạn biết chính xác những gì params cần phải được thêm vào.

Nếu bạn đang viết truy vấn này ở một số nơi có thể thay đổi mọi thứ

0

Tôi nghĩ rằng có thể có các truy vấn "nội tuyến" miễn là chúng không được lặp lại ở một số nơi. Nếu điều đó bắt đầu xảy ra, thì bạn có thể muốn bắt đầu tạo các lớp truy vấn.

5

Không tệ khi đặt chữ trực tiếp trong phương thức, miễn là bạn luôn gọi cùng một phương thức đó mỗi lần bạn muốn chạy truy vấn đó. Tuy nhiên, nếu bạn sẽ sao chép chuỗi ký tự đó thành nhiều vị trí trong mã của bạn, thì một hằng số chắc chắn được ưu tiên. Tuy nhiên, thay vì lấy một chuỗi làm đối số cho phương thức truy vấn trong ví dụ thứ hai của bạn, nó phải có một giá trị đếm.

Tuy nhiên, nếu bạn đang sử dụng phương pháp thứ hai mà bạn mô tả, tôi sẽ hỏi bạn tại sao bạn không chỉ bắt đầu sử dụng các thủ tục được lưu trữ thay thế?

+1

Điểm tốt trên các procs được lưu trữ –

+0

@Steven Doggart - Trong trường hợp của tôi, hai lý do: có quá nhiều ppl với quyền quản trị đối với db (người không nên có) và để giữ các truy vấn dưới sự kiểm soát souce. – user1481183

0

Trong cả hai trường hợp bạn đang rốt cuộc xây dựng/lấy String đó bạn sẽ chuyển đến CommandText. Vì vậy, sẽ không có sự khác biệt như vậy. Chỉ có điều bạn cần cân nhắc trong trường hợp của mình là cách bạn sẽ duy trì mã hoặc cách người khác hiểu mã của bạn.

0

Nếu bạn định sử dụng SQL nội tuyến ít nhất thì đừng đặt nó vào mã trang web vì nó sẽ gây đau khi bạn thực hiện thay đổi cơ sở dữ liệu để biết nó ảnh hưởng đến cái gì. Việc đặt tất cả các truy vấn trong một lớp có thể bị vô hiệu hóa một chút, nhưng nếu bạn nhóm chúng theo các lớp chức năng (như các lớp quản lý cho các đối tượng nghiệp vụ của bạn) thì có thể dễ dàng giải quyết hơn.

4

Tôi khuyên bạn nên sử dụng các thủ tục được lưu trữ làm giải pháp tốt hơn cho vấn đề của mình hơn các truy vấn nội dòng được mã hóa cứng. Nếu bạn phải thay đổi truy vấn vào một ngày sau đó, bạn không phải xây dựng lại ứng dụng của mình, vì vậy các lỗi trong truy vấn của bạn có thể được sửa mà không cần triển khai toàn bộ ứng dụng. Tùy chọn thứ 2 bạn có là một cơn ác mộng bảo trì đang chờ xảy ra. Tất cả đều trông rất đẹp khi bạn có một hoặc hai truy vấn trong đó, nhưng điều đó bắt đầu trông xấu hơn một chút khi bạn có hàng chục hoặc hàng trăm trong đó.Mã của bạn có vẻ như nó là C#, vì vậy tôi sẽ khuyên bạn nên xem Microsoft doanh nghiệp Thư viện,

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

Bạn có thể cần phải tải về một phiên bản khác nhau tùy thuộc vào những gì phiên bản của .NET framework bạn đang phát triển với.

0

Nếu bạn hoàn toàn phải có "inline" sql như trái ngược với các thủ tục lưu trữ (và tôi đã làm điều này cho các ứng dụng loại tiện ích mà chỉ đơn thuần là tương tác với một cơ sở dữ liệu, chứ không phải là riêng nó), tôi sẽ đề nghị đặt SQL của bạn thành một số embedded resource file. Điều này sẽ giúp truy vấn của bạn dễ bảo trì hơn (mặc dù bạn vẫn sẽ cần phải biên dịch lại ứng dụng của mình để thực hiện thay đổi).

0

Nếu truy vấn của bạn dài hơn một hoặc hai dòng, bạn nên xem xét việc đặt chúng trong tệp .sql của riêng chúng. Đặt hành động xây dựng trên tệp thành tài nguyên được nhúng và truy cập nó bằng lệnh gọi hàm GetManifestResourceStream(). Bằng cách đó, bạn đang nâng cao sql của bạn để tình trạng của một ngôn ngữ thích hợp, với cú pháp tô sáng, xác nhận và intellisense (khi bạn kết nối VS DB của bạn). Không cần phải nói, điều này cực kỳ tạo điều kiện bảo trì.

Nếu tất cả điều này có vẻ phức tạp, hãy lấy phần mở rộng VS của tôi, QueryFirst. Tạo các tệp .sql của bạn với mẫu được cung cấp và chúng sẽ tự động được kết nối để biên dịch. Nhưng bạn sẽ không quan tâm vì bạn sẽ chỉ truy cập các truy vấn thông qua các lớp được tạo ra.

Sql là ngôn ngữ máy tính duy nhất tôi có thể nghĩ rằng chúng tôi chấp nhận để xem xén nhỏ trong chuỗi ký tự. Nó phải là một vụ bê bối.

Các vấn đề liên quan