Di chuyển từ JPA trở lại SQL đơn giản

Question

Sau nhiều năm phát triển với TopLink/EclipseLink trong một ứng dụng sản xuất với khoảng 100 bảng, chúng tôi đã quyết định rằng đủ là đủ và JPA không đáng giá thêm phức tạp và không chắc chắn về hoạt động thực tế của nó, và rằng SQL (với một số wrapper như DBUtil hoặc một cái gì đó như thế) có thể làm công việc phù hợp với chúng ta.

Bạn có thể đề xuất cách di chuyển ứng dụng JPA khá lớn sang JDBC/SQL theo cách để JPA vẫn hoạt động (tức là trong webapp với GUI) nhưng điều đó sẽ cho phép chúng tôi vẫn bắt đầu với " hạ cấp xuống JDBC?

Chúng tôi có các thực thể và DAO, nhưng lo lắng thực sự của tôi là thực thể JPA (chính) - có thể vô hiệu hóa nó hoàn toàn để JPA hoạt động như một kết nối đơn giản.begin(); mục nhập ... connection.commit(); trong thời gian tạm thời, cho đến khi chúng ta thoát khỏi nó cho tốt?

Answer 1

Tôi hy vọng các bạn có một số bài kiểm tra đơn vị và tích hợp tốt. Nếu không, thì đây là nơi bắt đầu.

Sau đó, trong bước đầu tiên bạn có thể tạo abstract factory thông qua đó bạn cung cấp quyền truy cập vào tất cả các DAO và thực thể của bạn và thay đổi tất cả quyền truy cập từ khách hàng để đi qua nhà máy đó. Trong bước này, bạn sẽ phải cung cấp một triển khai cho nhà máy đó, tạo ra một nhà máy bê tông JpaAccessFactory và để các phương thức của nó trả về các DAO và các thực thể được điền bằng JPA.

Khi bạn chắc chắn không có gì xảy ra với bước đầu tiên. sau đó tiến hành bước thứ hai.

Tạo triển khai nhà máy SqlAccessFactory phù thủy điền vào các DAO và thực thể (đối tượng của các lớp thực thể ở đây thực sự chỉ DAO) bằng cách sử dụng SQL. Viết một số bài kiểm tra đơn vị phù thủy sử dụng cả hai nhà máy và thực hiện các xác nhận sử dụng expected được cung cấp bởi JpaAccessFactory và actual được cung cấp bởi SqlAccessFactory.

Khi bạn thực hiện xong phương pháp nhà máy cho bảng và tất cả các phụ thuộc của nó trong SqlAccessFactory, hãy để khách hàng/trang sử dụng DAO hoặc thực thể được cung cấp theo phương pháp này, sử dụng nhà máy mới để truy xuất nó. Bạn có thể làm cho cấu hình này, do đó bạn sẽ không phải thay đổi mã để thay đổi nhà máy phù thủy là beeing được sử dụng. Điều này cũng sẽ có lợi ích để dễ dàng chuyển đổi trở lại nếu bạn phát hiện ra rằng một cái gì đó không phải là nó nên được.

phương pháp Factory phù thủy chưa được thực hiện trong SqlAccessFactory chỉ có thể ném một ngoại lệ

throw new UnsupportedOperationException 
    ("Not yet implemented, please configure your client/page to use JPA."); 

Tôi hy vọng điều này sẽ cho một số gợi ý một nơi và làm thế nào để bắt đầu.

Answer 2

Ý tưởng sẽ là giới thiệu một lớp kho lưu trữ. Bạn giới thiệu kho và nhanh chóng triển khai api lõi với JPA, có thể tái sử dụng khá nhiều mã truy cập dữ liệu hiện có.

Vấn đề là trong cùng một thời điểm bạn bắt đầu cấu trúc lại toàn bộ ứng dụng để sử dụng kho lưu trữ thay vì JPA trực tiếp. Sau đó, một nhóm khác có thể làm việc trên các kho được thực hiện với jdbc thuần túy và kiểm tra việc thực thi jdbc chống thực thi jpa - vì các kho lưu trữ jdbc và jpa thực hiện cùng một bộ giao diện, các kiểm tra tuân thủ là hiển nhiên.

Để tóm tắt, sau xảy ra đồng thời:

• bạn thiết kế lớp giao diện của bạn để đáp ứng các nhu cầu của mã số kinh doanh thực tế
• bạn thực hiện các kho với mã JPA hiện
• bạn Refactor mã số kinh doanh của bạn để sử dụng kho lưu trữ
• bạn triển khai cùng một kho lưu trữ với jdbc và triển khai các kiểm tra tuân thủ

Tất cả là tất cả. Khi có đủ tự tin, bạn chỉ cần chuyển các cài đặt kho lưu trữ của mình sang các kho lưu trữ jdbc và giữ các kho lưu trữ jpa của bạn chỉ để kiểm tra khả năng tương thích ngược.