Mã sạch, đậu phiên không trạng thái và trạng thái riêng

Question

Theo mã sạch của phương pháp Robert C. Martin nên có chữ ký nhỏ. Trường hợp tốt nhất sẽ là một phương pháp không có tham số nào cả. Thay vào đó, bạn nên sử dụng các biến trạng thái. Điều này thực sự hữu ích. Nhưng những gì về đậu phiên không quốc tịch?

Tên là loại khó hiểu vì SLSB có thể có trạng thái. Bạn chỉ cần làm vệ sinh của bạn để bạn không sử dụng nhà nước từ các cuộc gọi EJB trước đó.

Quay lại mã sạch: Tôi cũng muốn sử dụng các biến mẫu trong SLSB. Điều này làm việc tốt và nếu bạn cẩn thận, bạn không gặp bất kỳ rắc rối nào với sự mâu thuẫn của tiểu bang kể từ khi tiểu bang được ghi đè trên mỗi cuộc gọi phương thức công khai.

Cho đến nay rất tốt. Nhưng điều gì sẽ xảy ra nếu một bean được sử dụng quay lại hồ bơi? Nó có trạng thái của nó với nó. Tùy thuộc vào kích thước của nhà nước này có thể là một rò rỉ bộ nhớ thực sự. JBoss rất hào phóng với hạt cà phê và tạo ra khá nhiều trong số chúng gây ra một số tiêu thụ bộ nhớ nghiêm trọng - không có gì.

Vì vậy, có một cách để dọn sạch trạng thái trước khi phương thức bean tồn tại và bean được trả về hồ bơi. Nhưng điều này dường như với tôi như mã vô dụng mà nên tránh.

Có cách nào phù hợp để giải quyết vấn đề này không? Thực hành tốt nhất trong tình huống này là gì?

Answer 1

Giữ cho cuộc sống trở nên đơn giản, chỉ cần truyền tham số. Ngay cả khi bạn có thể làm khác, rõ ràng là từ ý định của EJB không quốc tịch bạn không nên.

FWIW nhằm mục đích cho các tham số bằng 0 có vẻ ngớ ngẩn đối với tôi. Mục tiêu cho vài, vâng, nhưng cố gắng không vì lợi ích riêng của nó chỉ là daft.

Answer 2

theo mã sạch bởi phương pháp Robert C. Martin phải có chữ ký nhỏ .

Thông thường tôi muốn chuyển vào (đối tượng chuyển) làm đối số, theo cách này tôi có thể thay đổi nội dung tôi chuyển vào mà không ảnh hưởng đến chữ ký phương thức.

Ngoài ra, tôi muốn chuyển vào giao diện thay vì lớp cơ sở thực tế.

public void doSomething(IMyTransferObject arg){ 
... 
} 

đâu IMyTransferObject là một giao diện

interface IMyTransferObject { 
    ... 
} 

class TransferObject implements IMyTransferObject{ 
    private String name; 
    private String game; 
    ... accessor/mutator 
} 

Trường hợp tốt nhất sẽ là một phương pháp không có tham số nào cả. Thay vào đó, được khuyến nghị sử dụng các biến trạng thái. Điều này thực sự hữu ích. Nhưng những gì về đậu phiên không trạng thái?

Điều này không thể theo sau một cách tôn giáo, và không có lý do nào để thực hiện điều đó.

Answer 3

Từ http://docs.oracle.com/javaee/6/tutorial/doc/gipjg.html:

Stateless Session Beans

Một stateless session bean không duy trì một trạng thái đàm thoại với khách hàng. Khi khách hàng gọi phương thức của đậu không quốc tịch, các biến mẫu của bean có thể chứa trạng thái cụ thể cho ứng dụng khách đó nhưng chỉ trong thời gian yêu cầu . Khi phương pháp kết thúc, không được giữ lại trạng thái máy khách cụ thể . Tuy nhiên, khách hàng có thể thay đổi trạng thái của các biến mẫu trong các bean không trạng thái gộp, và trạng thái này được giữ cho lần gọi tiếp theo của bean không trạng thái gộp chung. Ngoại trừ trong khi gọi phương thức, tất cả các phiên bản của một bean không quốc tịch là tương đương, cho phép vùng chứa EJB gán một cá thể cho bất kỳ ứng dụng nào. Nghĩa là trạng thái của phiên phiên không trạng thái sẽ áp dụng trên tất cả các máy khách.

Tôi không phải là chuyên gia về EE, nhưng điều này nghe có vẻ là tôi được phép sử dụng các lĩnh vực theo cách bạn lập kế hoạch.

Tôi cho rằng bạn có để đảm bảo rằng với mỗi lời gọi phương thức mới, các instance fields được cập nhật với các dữ liệu mới, và tôi nghĩ rằng bạn nên chắc chắn rằng bạn đang loại bỏ các tài liệu tham khảo sau khi phương pháp này đã kết thúc để đảm bảo bạn không chặn bộ sưu tập rác của các đối tượng cũ chỉ vì chúng được tham chiếu trong một số bean "cũ" vẫn được giữ trong một số nhóm.

tôi sẽ đề nghị một mô hình như thế:

public class MyBean{ 

    private SomeClass firstObject; 
    private SomeOtherClass anotherObject; 
    private AndAnotherClass thirdObject; 

    public void theMethod(firstObject, anotherObject, thirdObject){ 
    try { 
     this.firstObject = firstObject; 
     this.anotherObject = anotherObject; 
     this.third = thirdObject; 

     startProcessing(); 

    }finally { 
     this.firstObject = null; 
     this.anotherObject = null; 
     this.third = null; 
    } 
    } 

    private void startProcessing() { 
    doStep1(); 
    doStep2(); 
    doStep3(); 
    } 

    [...] 
} 

Vẫn còn rất nhiều mã - nhưng nếu bạn dính vào một cách nhất quán với phong cách đó, bạn sẽ tự động bỏ qua "theMethod" một phần và tiếp tục đọc tại "startProcessing", nơi bạn có mọi thứ sạch sẽ và không có thông số.

Answer 4

Hoàn toàn có thể giữ các biến mẫu trong SLSB, vì bạn không sử dụng proxy thực hiện cuộc gọi giữa các phương thức. Ví dụ:

@Stateless 
public class MyEJB { 
    private String var; 

    public void receiveVar(String var) { 
     this.var = var; 
     useVar(); 
    } 

    private void useVar() { 
     // do something with var 
    } 
} 

Vấn đề là: khi bạn tiêm SLSB này vào một cuộc gọi khác, bất kỳ cuộc gọi phương thức nào cũng sẽ đi qua proxy để đạt được EJB thực tế. Vì vậy, xem xét rằng trường hợp thực được lấy từ các hồ bơi khi phương pháp được gọi là trên trường hợp proxy, không có đảm bảo rằng proxy sẽ sử dụng cùng một trường hợp gộp giữa hai hoặc nhiều cuộc gọi. Vì vậy, không thể đảm bảo giá trị của bất kỳ thuộc tính lớp được khai báo nào.

Khi SLSB quay trở lại hồ bơi, nó tự mang theo mọi giá trị đã định sẵn (tôi nghĩ rằng nó có thể thay đổi theo nhà cung cấp, tôi không thực sự chắc chắn). Nhưng, hoàn toàn có thể (và chấp nhận được) rằng một cá thể SLSB gộp lại đã có một giá trị thuộc tính được cấu hình trước đó.

tôi không hiểu quan điểm của bạn ở đây:

Cho đến nay rất tốt. Nhưng điều gì sẽ xảy ra nếu một bean được sử dụng quay lại hồ bơi? Mất trạng thái của nó với nó. Tùy thuộc vào kích thước của nhà nước này có thể là một rò rỉ bộ nhớ thực sự.JBoss là rất hào phóng với đậu và tạo ra khá nhiều trong số họ gây ra một số bộ nhớ nghiêm trọng tiêu thụ - cho không có gì.

Bạn có ví dụ nào về "trạng thái lớn" mà bạn có thể có trong SLSB không?

Và cuối cùng:

Tôi nghĩ cách tốt nhất để xử lý các giá trị luôn xử lý các biến trạng thái mà bạn sẽ sử dụng. Đặt trước và lau chùi sau khi sử dụng. Và cách tốt nhất là tránh tình huống khó hiểu này.

Hy vọng điều đó sẽ hữu ích.