Thuật ngữ Plain Old Java Object (POJO) có nghĩa là gì?

Question

Thuật ngữ Đối tượng Java cũ đơn giản (POJO) là gì? Tôi không thể tìm thấy bất cứ điều gì giải thích đủ.

POJO's Wikipedia page cho biết POJO là một đối tượng Java thông thường chứ không phải đối tượng đặc biệt. Bây giờ, những gì tạo ra hoặc những gì không tạo và đối tượng đặc biệt trong Java?

Trang trên cũng cho biết rằng POJO không nên mở rộng các lớp được xác định trước, triển khai Giao diện đã được xác định trước hoặc chứa Chú thích được xác định trước. Điều đó cũng có nghĩa là POJO không được phép triển khai các giao diện như Serializable, Comparable hoặc các lớp như Applet hoặc bất kỳ Lớp/Giao diện người dùng nào khác?

Ngoài ra, chính sách ở trên (không mở rộng, không triển khai) có nghĩa là chúng tôi không được phép sử dụng bất kỳ thư viện bên ngoài nào không?

Trường hợp POJO được sử dụng chính xác ở đâu?

EDIT: Cụ thể hơn, tôi có được phép mở rộng/triển khai các lớp/giao diện là một phần của Java hoặc bất kỳ thư viện bên ngoài nào không?

Answer 1

Đối tượng Java cũ đơn giản :)

Vâng, bạn làm cho âm thanh như thể tất cả đều là những hạn chế khủng khiếp.

Trong bối cảnh thông thường nơi POJO được/được sử dụng, nó giống như một lợi ích:

Nó có nghĩa rằng bất cứ thư viện/API bạn đang làm việc với là hoàn toàn sẵn sàng để làm việc với các đối tượng Java chưa được doctored hoặc manhandled trong bất kỳ cách nào, tức là bạn không phải làm bất cứ điều gì đặc biệt để có được họ làm việc.

Ví dụ, bộ xử lý XML XStream sẽ (tôi nghĩ) vui vẻ tuần tự hóa các lớp Java không triển khai giao diện Serializable. Đó là một lợi thế! Nhiều sản phẩm hoạt động với các đối tượng dữ liệu được sử dụng để buộc bạn triển khai SomeProprietaryDataObject hoặc thậm chí mở rộng lớp AbstractProprietaryDataObject. Nhiều thư viện sẽ mong đợi hành vi của đậu, tức là getters và setters.

Thông thường, mọi thứ hoạt động với POJO cũng sẽ hoạt động với các điểm không phải của PO-JO. Vì vậy, XStream sẽ dĩ nhiên cũng serialize các lớp Serializable.

Answer 2

POJO là một đối tượng Java cũ đơn giản - so với thứ cần thứ gì đó (J2EE) của Enterprise Edition (đậu, v.v ...).

POJO không thực sự là định nghĩa cứng và nhanh, và nhiều cách khác để mô tả các đối tượng Java không phải doanh nghiệp "bình thường". Việc sử dụng một thư viện bên ngoài hoặc khung làm cho một đối tượng POJO hay không là loại mắt của người xem, phần lớn phụ thuộc vào thư viện/khung làm việc, mặc dù tôi muốn mạo hiểm để đoán rằng một khuôn khổ sẽ làm cho cái gì đó ít hơn của POJO

Answer 3

Cách sử dụng thuật ngữ ngụ ý những gì nó phải cho bạn biết. Ví dụ, nếu khung tiêm phụ thuộc cho bạn biết rằng bạn có thể tiêm POJO vào bất kỳ POJO nào khác mà họ muốn nói rằng bạn không phải làm bất cứ điều gì đặc biệt: không cần tuân theo bất kỳ hợp đồng nào với đối tượng của bạn, hãy thực hiện bất kỳ giao diện nào hoặc mở rộng các lớp đặc biệt. Bạn chỉ có thể sử dụng bất cứ điều gì bạn đã có.

CẬP NHẬT Để cung cấp một ví dụ khác: trong khi Hibernate có thể lập bản đồ bất kỳ POJO (bất kỳ đối tượng mà bạn đã tạo) để bảng SQL, trong Core Data (C Mục tiêu trên iPhone) đối tượng của bạn cần phải mở rộng NSManagedObject để cho hệ thống để có thể lưu chúng vào cơ sở dữ liệu. Theo nghĩa đó, Core Data không thể làm việc với bất kỳ POJO nào (hay đúng hơn là POOCO = PlainOldObjectiveCObject) trong khi Hibernate có thể. (Tôi có thể không phải bằng 100% chính xác lại dữ liệu cốt lõi kể từ khi tôi chỉ mới bắt đầu nhặt nó lên. Bất kỳ gợi ý/sửa chữa được chào đón :-)).

Answer 4

According to Martin Fowler, ông và một số người khác đã đưa ra với nó như một cách để mô tả một cái gì đó mà là một lớp học tiêu chuẩn như trái ngược với một EJB, vv

Answer 5

Toàn bộ vấn đề của một POJO là sự đơn giản và bạn dường như đang giả định một cái gì đó phức tạp hơn nó xuất hiện.

Nếu thư viện hỗ trợ POJO, nó ngụ ý rằng đối tượng của bất kỳ lớp nào đều có thể chấp nhận được. Nó không có nghĩa là POJO không thể có chú thích/giao diện hoặc chúng sẽ không được sử dụng nếu chúng ở đó, nhưng nó không phải là một yêu cầu.

IMHO Trang wiki khá rõ ràng. Nó không nói một POJO không thể có chú thích/giao diện.

Answer 6

Đối tượng Java cũ đơn giản Tên được sử dụng để nhấn mạnh rằng đối tượng đã cho là đối tượng Java thông thường, không phải là đối tượng đặc biệt như đối tượng được xác định bởi khung EJB 2.

class A {}
lớp B kéo dài/thực hiện C {}

Lưu ý: B là phi POJO khi C là loại phân lớp khung hoặc IFC. ví dụ: javax.servlet.http.HttpServlet, javax.ejb.EntityBean hoặc J2EE mở rộng và không thể tuần tự/so sánh được. Vì serializable/comparable có giá trị cho POJO.

Ở đây A là đối tượng đơn giản độc lập. B là obj đặc biệt vì B đang mở rộng/triển khai C. Vì vậy đối tượng B nhận được một số ý nghĩa từ C và B là hạn chế tuân theo các quy tắc từ C. và B là chặt chẽ cùng với với khung phân phối. Do đó đối tượng B không phải là POJO từ định nghĩa của nó.

Mã sử ​​dụng lớp Một tham chiếu đối tượng không cần phải biết bất kỳ điều gì về loại hình này và nó có thể được sử dụng với nhiều khung công tác.

Vì vậy, POJO không cần phải 1) mở rộng các lớp được xác định trước và 2) Triển khai các giao diện đã được xác định trước.

JavaBean là một ví dụ về POJO có thể tuần tự hóa, có hàm tạo không đối số và cho phép truy cập vào các thuộc tính bằng cách sử dụng các phương thức getter và setter tuân theo quy ước đặt tên đơn giản.

POJO hoàn toàn tập trung vào logic nghiệp vụ và không phụ thuộc vào khung công tác (doanh nghiệp). Nó có nghĩa là nó có mã cho logic nghiệp vụ nhưng cách thể hiện này được tạo ra, Dịch vụ nào (EJB ..) đối tượng này thuộc về và đặc điểm đặc biệt của nó (Stateful/Stateless) nó sẽ được quyết định bởi khung công tác bằng cách sử dụng bên ngoài tệp xml.

Ví dụ 1: JAXB là dịch vụ đại diện cho đối tượng java dưới dạng XML; Các đối tượng java này rất đơn giản và đi kèm với các hàm dựng và xây dựng mặc định.

Ví dụ 2: Hibernate nơi lớp java đơn giản sẽ được sử dụng để biểu diễn Bảng. cột sẽ là trường hợp của nó.

Ví dụ 3: Dịch vụ REST. Trong các dịch vụ REST chúng ta sẽ có Service Layer và Dao Layer để thực hiện một số thao tác trên DB. Vì vậy, Đào sẽ có các truy vấn và hoạt động cụ thể của nhà cung cấp. Lớp dịch vụ sẽ chịu trách nhiệm gọi lớp DAO nào để thực hiện các thao tác DB. Tạo hoặc cập nhật API (phương thức) của DAO sẽ nhận POJO làm đối số và cập nhật POJO và chèn/cập nhật vào DB. Các POJO (lớp Java) này sẽ chỉ có các trạng thái (các biến mẫu) của mỗi cột và các getters và setters của nó. Trong thực tế, một số người tìm thấy chú thích thanh lịch, trong khi họ thấy XML là tiết, xấu xí và khó duy trì, nhưng những người khác lại tìm thấy chú thích gây ô nhiễm cho mô hình POJO. Như vậy, như là một thay thế cho XML, nhiều khung (ví dụ như Spring, EJB và JPA) cho phép chú thích để được sử dụng thay hoặc bổ sung cho XML:

Ưu điểm:
Kết nối cho cặp mã ứng dụng từ các khuôn khổ cơ sở hạ tầng là một trong nhiều lợi ích của việc sử dụng POJO. Sử dụng POJO trong tương lai sẽ chứng minh logic nghiệp vụ của ứng dụng của bạn bằng cách tách nó khỏi các khung cơ sở hạ tầng không ổn định và không ngừng phát triển. Nâng cấp lên phiên bản mới hoặc chuyển sang một khung công tác khác trở nên dễ dàng hơn và ít rủi ro hơn. POJO cũng làm cho việc thử nghiệm dễ dàng hơn, giúp đơn giản hóa và tăng tốc phát triển. logic kinh doanh của bạn sẽ được rõ ràng hơn và đơn giản hơn bởi vì nó sẽ không được rối với các mã cơ sở hạ tầng

Tài liệu tham khảo: wikisource2

Answer 7

Một Plain Old Java Object (POJO) có chứa tất cả các logic kinh doanh gia hạn của bạn.

Exp. POJO trong đó có một phương pháp duy nhất

public class Extension { 
    public static void logInfo(String message) { 
     System.out.println(message); 
    } 
} 

Answer 8

nào hạn Plain Old Java Object (POJO) nghĩa là gì?

POJO được đặt ra bởi Martin Fowler, Rebecca Parsons và Josh Mackenzie khi họ đang chuẩn bị cho một cuộc nói chuyện tại một cuộc họp vào tháng năm 2000. Martin Fowler trong Patterns of Enterprise Application Architecture giải thích làm thế nào để thực hiện một mẫu Domain Model trong Java . Sau khi liệt kê một số nhược điểm của việc sử dụng EJB Entity Beans:

Luôn luôn có rất nhiều nhiệt sinh ra khi người ta nói về phát triển một mô hình miền trong J2EE. Nhiều tài liệu giảng dạy và sách giới thiệu J2EE gợi ý rằng bạn sử dụng các bean thực thể để phát triển mô hình miền , nhưng có một số vấn đề nghiêm trọng với cách tiếp cận này, ít nhất với đặc tả hiện tại (2.0).

đậu Entity là hữu ích nhất khi bạn sử dụng Container Managed Persistence (CMP) ...

Entity đậu không thể được tái ký dự thi. Tức là, nếu bạn gọi ra một hạt thực thể thành đối tượng khác, đối tượng kia (hoặc bất kỳ đối tượng nào nó gọi ) không thể gọi lại vào bean thực thể đầu tiên ...

... Nếu bạn có các đối tượng từ xa với giao diện hạt mịn bạn sẽ có được hiệu suất khủng khiếp ...

Để chạy với entity bean bạn cần một container và một cơ sở dữ liệu kết nối. Điều này sẽ tăng thời gian xây dựng và cũng tăng thời gian để chạy thử nghiệm vì các thử nghiệm phải thực thi dựa trên cơ sở dữ liệu. Các loại đậu thực thể cũng rất khó để gỡ lỗi.

Là một thay thế, ông đề nghị sử dụng Regular Java Objects thi Domain Model:

Cách khác là sử dụng bình thường các đối tượng Java, mặc dù điều này thường gây ra một phản ứng-nó ngạc nhiên là tuyệt vời có bao nhiêu người nghĩ rằng bạn không thể chạy các đối tượng Java thông thường trong một thùng chứa EJB. Tôi đã đến kết luận rằng mọi người quên về các đối tượng Java thông thường vì họ không có một cái tên lạ mắt. Đó là lý do tại sao, trong khi chuẩn bị cho một cuộc nói chuyện vào năm 2000, Rebecca Parsons, Josh Mackenzie, và tôi đưa cho họ một: POJOs (các đối tượng Java cũ đơn giản). Một mô hình miền POJO rất dễ dàng để kết hợp, có thể chạy nhanh và thử nghiệm bên ngoài vùng chứa EJB và là độc lập với EJB (có thể đó là lý do tại sao các nhà cung cấp EJB không khuyến khích bạn sử dụng chúng).