2010-03-17 37 views
5

Câu hỏi chung về ý kiến ​​của mọi người là lưu trữ các truy vấn SQL trong một tệp cấu hình?Lưu trữ truy vấn SQL trong tệp Cấu hình?

Đây có phải là một chiếc xe đạp khác không?

Chúc mừng, Bến

+0

Bạn có thể mở rộng về lý do bạn muốn. Tôi không nghĩ rằng đây là một trường hợp đơn giản của có/không và có thể có một cách tốt hơn, thay thế để đạt được những gì bạn đang sau. – CResults

+1

Xin lỗi chỉ để làm rõ tôi không có kịch bản cụ thể trong tâm trí và chỉ đơn thuần là tìm kiếm quan điểm về chủ đề này. –

Trả lời

1

Đó là những gì bạn muốn làm gì nếu bạn đang sử dụng iBatis. Tôi không thấy tác hại trong nó.

Chắc chắn nhịp đập sẽ tự động xây dựng chúng khi không cần thiết.

1

Không bao giờ. Nghiêm túc;) Làm sạch ở đây vào lúc này.

Hãy thử xem BLToolkit - lưu trữ chúng trong thuộc tính ngay trên lớp trừu tượng, chúng tự động tạo toàn bộ mã truy cập dưới. Tương tự như sử dụng nó trong tập tin cấu hình, nhưng không cần viết hoặc nhìn thấy mã DAL ngu ngốc.

2

Nghe có vẻ không tệ với tôi, miễn là nó đáp ứng các yêu cầu.

Bạn đang cố gắng cho phép khách hàng xem và chỉnh sửa truy vấn?

Bạn đang cố gắng làm cho việc phát triển/thử nghiệm trở nên dễ dàng hơn?

Tôi chắc chắn thích điều này để nhúng các truy vấn vào mã.

Nhưng có rủi ro là tệp này sẽ sưng lên với vô số các truy vấn hơi khác nhau (SORT ASCENDING, SORT DESCENDING, SUM (col1) + SUM (col2), SUM (col1) + SUM (col3), v.v.)

1

trong trường hợp đó, tôi muốn lưu trữ chúng trong db:

  1. sẽ làm cho nó khó khăn hơn cho joe thường xuyên để fiddle xung quanh với các truy vấn của tôi và gây nguy hiểm cho ứng dụng của tôi.
  2. Họ không thể suy ra cách tôi lưu trữ dữ liệu của mình.
  3. Các thay đổi sẽ được phản ánh tự động mà không cần phải "đẩy" tệp cấu hình.

Nhưng thực sự, tôi ngoại suy mà không biết kịch bản thực tế của bạn. Nhưng tắt còng, tôi không muốn người khác thấy cách tôi tương tác với lược đồ của tôi hoặc cách nó được đặt ra.

1

Lý do bạn đặt chúng ở bất kỳ đâu ngoài mã? Tôi đã thấy rằng thường xuyên hơn không thay đổi SQL ở cùng tốc độ với mã của bạn, có nghĩa là nếu bạn thay đổi UserDao.java bạn có thể sẽ phải thay đổi sql-statements.properties cùng một lúc. Với điều đó đang được nói, mã được đọc nhiều lần hơn nó được viết, vì vậy viết mã có thể đọc được là rất quan trọng trong một codebase sạch. Với các câu lệnh SQL trong một tệp riêng biệt, một nhà phát triển phải tìm nơi khác để tìm ra truy vấn UserDao của bạn sử dụng, làm cho việc hiểu mã của bạn khó khăn hơn.

Câu trả lời ngắn gọn? Tôi sẽ tránh nó nếu có thể.

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