Ưu điểm/nhược điểm của chú thích (không biên dịch) so với tệp cấu hình xml

Question

Khi tôi xem các khung công tác Java như Hibernate, JPA hoặc Spring, tôi thường có khả năng tạo cấu hình của mình thông qua tệp xml hoặc đặt chú thích trực tiếp trong lớp học của tôi.

Tôi đang tự hỏi bản thân mình nên đi theo cách nào.

Khi tôi sử dụng chú thích, tôi có lớp và cấu hình của nó với nhau nhưng với xml tôi nhận được bức tranh lớn hơn về hệ thống của mình vì tôi có thể thấy tất cả cấu hình lớp.

Chú thích cũng được biên dịch theo cách tôi đoán và nhanh hơn phân tích cú pháp xml, nhưng mặt khác, nếu tôi muốn thay đổi cấu hình, tôi phải biên dịch lại thay vì chỉ thay đổi tệp xml (có thể trở nên tiện dụng hơn cho môi trường sản xuất ở phía khách hàng).

Vì vậy, khi nhìn vào điểm của mình, tôi có xu hướng đi theo hướng xml. Nhưng khi nhìn vào diễn đàn hoặc hướng dẫn thường chú thích được sử dụng.

Ưu và nhược điểm của bạn là gì?

Answer 1

Nguyên tắc chung: bất kỳ điều gì bạn có thể thấy mình muốn thay đổi mà không cần triển khai lại đầy đủ (ví dụ: thông số hiệu suất tinh chỉnh) thực sự phải có thứ gì đó "có thể cấu hình mềm" chẳng hạn như tệp XML. Bất kỳ thứ gì không bao giờ thực tế sẽ thay đổi - hoặc chỉ trong tình huống mà bạn sẽ phải thay đổi mã - có thể hợp lý trong một chú thích.

Bỏ qua bất kỳ ý tưởng nào về hiệu suất khác biệt giữa chú thích và XML - trừ khi cấu hình của bạn hoàn toàn là lớn sự khác biệt sẽ không đáng kể.

Tập trung vào tính linh hoạt và dễ đọc.

Answer 2

Nếu bạn đang viết một API, sau đó là một lời cảnh báo: Chú thích có thể bị rò rỉ ra giao diện công cộng của bạn, điều này có thể khiến bạn không thể tin nổi.

Tôi hiện đang làm việc với API nơi nhà cung cấp API đã thực hiện việc triển khai với chú thích Spring MBean, đột nhiên có nghĩa là tôi phụ thuộc vào thư viện Spring, mặc dù khả năng tôi không cần sử dụng Spring: (

(Tất nhiên, nếu API của bạn là một phần mở rộng để mùa xuân bản thân, điều này có thể là một giả định hợp lệ.)

Answer 3

tôi nghĩ rằng quyết định đi xuống đến 'vòng đời', và trở kháng không phù hợp giữa vòng đời.

Vòng đời: Mọi phần dữ liệu, cho dù mã nguồn của nó, một hàng cơ sở dữ liệu, một lớp được biên dịch, một đối tượng, có một vòng đời được liên kết với nó. Khi nào nó xuất hiện và khi nào rác được thu gom?

Giả sử tôi đặt chú thích Hibernate trên một lớp Java. Có vẻ như là một ý tưởng hợp lý, đặc biệt nếu tôi tạo một cơ sở dữ liệu mới từ đầu và tự tin rằng chỉ có một ứng dụng này sẽ kết nối với nó - vòng đời của các lớp của tôi, lược đồ cơ sở dữ liệu và ánh xạ ORM được đồng bộ một cách tự nhiên.

Bây giờ giả sử tôi muốn sử dụng cùng một lớp đó trong API và cung cấp cho một số bên thứ ba để tiêu thụ. Các chú thích Hibernate bị rò rỉ vào API của tôi. Điều này xảy ra vì vòng đời của lớp đó và cơ sở dữ liệu không giống nhau. Vì vậy, chúng tôi kết thúc bằng cách sử dụng các công cụ lập bản đồ để dịch giữa các lớp hạt trong một hệ thống.

Tôi cố gắng suy nghĩ về vòng đời và chú thích có thể gây ra sự không phù hợp vòng đời nên tránh. Một số chú thích tương đối vô hại về mặt này, và một số là một mối nguy hiểm tiềm ẩn.

Ví dụ về chú thích xấu: Lập bản đồ ORM, cấu hình cơ sở dữ liệu, cấu hình mã hóa cứng cho các mục có thể khác nhau giữa môi trường triển khai, xác thực có thể thay đổi tùy theo ngữ cảnh.

Ví dụ về chú thích vô hại: Định nghĩa điểm cuối REST, chuỗi tuần tự JSON/XML, xác thực luôn áp dụng.