2012-02-27 30 views
17

Từ những gì tôi hiểu, cả hai DataSourceJdbcTemplatesthreadsafe, vì vậy bạn có thể cấu hình một trường hợp duy nhất của một JdbcTemplate và sau đó tiêm một cách an toàn thông tin này chia sẻ thành nhiều DAO (hoặc kho). Ngoài ra DataSource phải là một singleton mùa xuân, vì nó quản lý hồ bơi kết nối.Nhiều phiên bản JdbcTemplate hay không?

Quan chức Spring Documentation JdbcTemplate best practices giải thích sự lựa chọn thay thế (trích đoạn từ cuốn hướng dẫn được in nghiêng, và ghi chú của tôi giữa dấu ngoặc vuông:

  • cấu hình một DataSource trong file cấu hình Spring của bạn, và sau đó phụ thuộc-bơm đã chia sẻ DataSource đậu vào các lớp DAO của bạn, JdbcTemplate được tạo ra trong setter cho DataSource [với cấu hình XML và điều này dẫn đến nhiều trường hợp JdbcTemplate, vì trong bộ dữ liệu setter có new JdbcTemplate(dataSource)]
  • sử dụng quét thành phần và hỗ trợ chú thích cho tiêm phụ thuộc. Trong trường hợp này, bạn chú thích lớp với @Repository (làm cho nó trở thành một ứng cử viên cho quét thành phần) và chú thích phương thức setter DataSource với @Autowired. [trường hợp này cũng dẫn đến nhiều trường hợp JdbcTemplate]
  • Nếu bạn đang sử dụng lớp JdbcDaoSupport của Spring và các lớp DAO được hỗ trợ JDBC khác nhau, thì lớp con của bạn thừa hưởng phương thức setDataSource (..) từ Lớp JdbcDaoSupport. Bạn có thể chọn có kế thừa từ lớp này hay không. Lớp JdbcDaoSupport chỉ được cung cấp dưới dạng tiện lợi. [kể từ khi bạn đã là một thể hiện của JdbcDaoSupport cho mỗi lớp mở rộng nó, có một thể hiện của JdbcTemplate quá cho mỗi thể hiện của lớp được thừa kế (xem source code for JdbcDaoSupport)]

Tuy nhiên, một lưu ý sau, không khuyến khích tất cả các các tùy chọn vừa được trình bày:

Sau khi được định cấu hình, một cá thể JdbcTemplate là luồng an toàn. Bạn có thể muốn nhiều cá thể JdbcTemplate nếu ứng dụng của bạn truy cập nhiều cơ sở dữ liệu, đòi hỏi nhiều DataSources và sau đó là nhiều JdbcTemplates được định cấu hình khác nhau.

Nói cách khác, tất cả các tùy chọn vừa trình bày sẽ dẫn đến có nhiều phiên bản JdbcTemplate (một cho mỗi DAO) và ngay sau khi tài liệu nói rằng không cần thiết khi làm việc với một cơ sở dữ liệu.

Điều tôi sẽ làm là tiêm trực tiếp JdbcTemplate đến các DAO khác nhau cần nó, vì vậy câu hỏi của tôi là, liệu có ổn không? Và bạn cũng nghĩ rằng tài liệu tham chiếu Spring là tự mâu thuẫn? Hay là sự hiểu lầm của tôi?

+2

Chỉ cần sử dụng một nguồn dữ liệu/JdbcTemplate mỗi cơ sở dữ liệu chương trình – tom

+0

tài liệu Mùa xuân không tự mâu thuẫn. Bạn nên đọc câu lệnh trước đó - Bất kể bạn đang sử dụng kiểu mẫu nào ở trên (hoặc không), ít khi cần tạo một cá thể mới của một lớp JdbcTemplate mỗi khi bạn muốn thực thi SQL. Thực hành tốt nhất là một JdbcTemplate mỗi dao. Nhiều JdbcTemplates nếu bạn muốn nhiều DataSources chỉ. – hutingung

Trả lời

2

IMO, không có vấn đề gì khi đưa JdbcTemplate vào (nhiều) DAO của bạn. Mẫu được sử dụng để "nối" DAO của bạn với tài nguyên vật lý (kết nối db) khi bạn cần chạy truy vấn db. Vì vậy, nếu SessionFactory và TransactionManager được cấu hình đúng, bạn sẽ không chạy vào các vấn đề tương tranh - Spring quản lý vòng đời của các bean mà bạn cần để làm việc với bạn persistence layer. Ưu điểm của việc sử dụng mẫu là:

  1. Mẫu JDBC quản lý tài nguyên vật lý cần thiết để tương tác với DB tự động, ví dụ: tạo và phát hành các kết nối cơ sở dữ liệu.
  2. Mẫu Spring JDBC chuyển đổi các SQLExceptions JDBC chuẩn thành RuntimeExceptions.Điều này cho phép bạn phản ứng linh hoạt hơn với các lỗi. Spring JDBC mẫu cũng chuyển đổi các thông báo lỗi nhà cung cấp cụ thể vào các thông báo lỗi có thể hiểu tốt hơn
0

vì vậy nó nên bị đổ ra hai tình huống:

Chúng tôi không thay đổi thuộc tính JdbcTemplate trong DAO, chúng ta có thể xác định như sau:

<bean id="tlmJDBCTemplate" class="org.springframework.jdbc.core.JdbcTemplate"    <property name="dataSource" ref="plmTlmDataSource"/>   
    </bean> 

LƯU Ý: Hầu hết thời gian chúng tôi không thay đổi thuộc tính JdbcTemplate, vì không cần thiết.

Chúng tôi thay đổi các thuộc tính JdbcTemplate trong DAO, chúng ta nên mở rộng JdbcDaoSupport.

State: 
• fetchSize: If this variable is set to a non-zero value, it will be used for setting the fetchSize property on statements used for query processing(JDBC Driver default) 
• maxRows: If this variable is set to a non-zero value, it will be used for setting the maxRows property on statements used for query processing(JDBC Driver default) 
• queryTimeout: If this variable is set to a non-zero value, it will be used for setting the queryTimeout property on statements used for query processing.(JDBC Driver default) 
• skipResultsProcessing: If this variable is set to true then all results checking will be bypassed for any callable statement processing. This can be used to avoid a bug in some older Oracle JDBC drivers like 10.1.0.2.(false) 
• skipUndeclaredResults: If this variable is set to true then all results from a stored procedure call that don't have a corresponding SqlOutParameter declaration will be bypassed. All other results processing will be take place unless the variable {@code skipResultsProcessing} is set to {@code true}(false) 
• resultsMapCaseInsensitive: If this variable is set to true then execution of a CallableStatement will return the results in a Map that uses case insensitive names for the parameters if Commons Collections is available on the classpath.(false) 
  1. JdbcDaoSupport

    public class trừu tượng JdbcDaoSupport kéo dài DaoSupport {

    private JdbcTemplate jdbcTemplate; 
    
    
    /** 
    * Set the JDBC DataSource to be used by this DAO. 
    */ 
    public final void setDataSource(DataSource dataSource) { 
        if (this.jdbcTemplate == null || dataSource != this.jdbcTemplate.getDataSource()) { 
         this.jdbcTemplate = createJdbcTemplate(dataSource); 
         initTemplateConfig(); 
        } 
    } 
    

Tóm lại: Tôi không nghĩ rằng mùa xuân cho việc thực hành trong hướng dẫn là tốt nhất.

0

Mùa xuân có ý nghĩa rất tinh tế về các phương pháp hay nhất.

JdbcTemplate có chủ đề an toàn, đáng chú ý là không có khóa (v4.2.4). Có nghĩa là nó không nên gây suy giảm hiệu năng khi được chia sẻ giữa các chủ đề đồng thời *. Vì vậy, không có lý do thuyết phục nào cho nhiều hơn một cá thể trên mỗi nguồn dữ liệu.

Ghi chú đầu cơ: phần này thực sự gây nhầm lẫn. Có lẽ do lý do lịch sử (tiến hóa). Có lẽ mùa xuân đã có một chính sách dao trong quá khứ do an toàn không thread hoặc understading nghèo của tên miền tại một thời điểm. Tương tự như cấu hình dựa trên xml "thảm họa". Ngày nay, mùa xuân từ bỏ quan điểm có ý kiến ​​và cố gắng linh hoạt thay thế. Thật không may, điều này đã dẫn đến những lựa chọn thiết kế tồi chỉ được công nhận một cách bí mật.

* Biện pháp không đoán

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