Mùa xuân AOP vs AspectJ

Tôi có ấn tượng rằng Spring AOP được sử dụng tốt nhất cho các tác vụ cụ thể của ứng dụng như bảo mật, ghi nhật ký, giao dịch, v.v. vì nó sử dụng các chú thích Java5 tùy chỉnh làm khung. Tuy nhiên, AspectJ dường như thân thiện hơn với các mẫu thiết kế.

Bất cứ ai cũng có thể nêu bật những ưu và nhược điểm khác nhau của việc sử dụng Spring AOP vs AspectJ trong ứng dụng Spring?

Ưu điểm mùa xuân

• Sử dụng đơn giản hơn AspectJ, vì bạn không phải sử dụng LTW ( dệt thời gian tải ) hoặc trình biên dịch AspectJ.

• Nó sử dụng mẫu Proxy và mẫu Trang trí

Nhược điểm mùa xuân

• Đây là AOP dựa trên proxy, vì vậy về cơ bản, bạn chỉ có thể sử dụng các điểm tham gia thực thi phương thức.
• Các khía cạnh không được áp dụng khi gọi một phương thức khác trong cùng một lớp.
• Có thể có một chút thời gian chạy trên đầu.
• Spring-AOP không thể thêm một khía cạnh vào bất cứ thứ gì không được tạo bởi nhà máy Spring

Ưu điểm AspectJ

• Điều này hỗ trợ tất cả các điểm tham gia. Điều này có nghĩa là bạn có thể làm bất cứ điều gì.
• Có ít thời gian chạy hơn so với Spring AOP.

Nhược điểm của AspectJ

• Hãy cẩn thận. Kiểm tra xem các khía cạnh của bạn được dệt để chỉ những gì bạn muốn được dệt.
• Bạn cần thêm quy trình xây dựng với AspectJ Compiler hoặc phải thiết lập LTW (dệt thời gian tải)

Ngoài những gì người khác đã nêu - chỉ để viết lại , there are two major differences:

1. Một là liên quan đến các loại dệt.
2. Khác với định nghĩa tham gia.

Spring-AOP: Thời gian chạy dệt thông qua proxy sử dụng khái niệm vềdynamic proxy if interface exists or cglib library if direct implementation provided.

AspectJ: Biên dịch thời gian dệt thông qua AspectJ Java Tools(ajc compiler)nếu nguồn có sẵn hoặc dệt biên dịch (sử dụng các tệp được biên dịch). Ngoài ra, thời gian tải dệt với Spring có thể được bật - nó cần aspectjtệp định nghĩa và cung cấp tính linh hoạt.

Biên dịch thời gian dệt có thể mang lại lợi ích của hiệu suất (trong một số trường hợp) và cả joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

Một lưu ý bổ sung: Nếu hiệu suất dưới tải cao là quan trọng, bạn sẽ muốn AspectJ nhanh hơn 9 - 35 lần so với Spring AOP . 10ns so với 355ns nghe có vẻ không nhiều, nhưng tôi đã thấy mọi người sử dụng RẤT NHIỀU khía cạnh. Các khía cạnh đáng giá 10K. Trong những trường hợp này, yêu cầu của bạn có thể đạt hàng ngàn khía cạnh. Trong trường hợp đó, bạn đang thêm ms vào yêu cầu đó.

Xem điểm chuẩn .

Hướng dẫn sử dụng lò xo sẽ cung cấp nhiều thông tin, trực tiếp từ miệng ngựa.

Chương 6.4 - Chọn kiểu khai báo AOP nào sẽ phù hợp với bạn vì nó thảo luận về ưu và nhược điểm của cả hai.

Đoạn 6.1.2 - Các mục tiêu và mục tiêu của Spring AOP & chương 6.2 - Hỗ trợ @Aspect và 6.8 - Sử dụng AspectJ với các ứng dụng Spring nên đặc biệt thú vị.

Spring AOP là một trong những phần thiết yếu của khung mùa xuân. Ở giai đoạn rất cơ bản, khung mùa xuân dựa trên IoC và AOP. Trong khóa học chính thức của Spring có một slide trong đó ghi:

AOP là một trong những phần quan trọng nhất của khung.

Điểm mấu chốt để hiểu cách AOP in Spring hoạt động là khi bạn viết Aspect with Spring, chúng tôi sẽ tạo khung cho việc xây dựng proxy cho các đối tượng của bạn, với JDKDynamicProxyviệc bean của bạn thực hiện giao diện hoặc thông qua CGLIB nếu bean của bạn không thực hiện bất kỳ giao diện. Hãy nhớ rằng bạn phải có cglib 2.2 trong đường dẫn lớp nếu bạn đang sử dụng Spring trước phiên bản 3.2. Bắt đầu từ Spring 3.2, nó vô dụng vì cglib 2.2 đã được đưa vào lõi.

Khung công tác tạo bean sẽ tạo ra một proxy bao bọc các đối tượng của bạn và thêm các trách nhiệm liên quan đến chéo như bảo mật, quản lý giao dịch, ghi nhật ký, v.v.

Việc tạo proxy theo cách này sẽ được áp dụng bắt đầu cho một biểu thức cắt điểm giúp công cụ khung quyết định loại đậu và phương thức nào sẽ được tạo dưới dạng proxy. Lời khuyên sẽ có trách nhiệm hơn so với mã của bạn. Hãy nhớ rằng trong quy trình này, điểm cắt chỉ ghi lại các phương thức công khai không được khai báo là cuối cùng.

Bây giờ, trong khi ở Spring AOP, việc dệt các khía cạnh sẽ được thực hiện bởi container khi khởi động container, trong AspectJ bạn phải thực hiện điều này với một bài tổng hợp mã của bạn thông qua sửa đổi mã byte. Vì lý do này theo tôi, cách tiếp cận Spring đơn giản và dễ quản lý hơn AspectJ.

Mặt khác, với Spring AOP, bạn không thể sử dụng toàn bộ sức mạnh của AOP vì việc triển khai được thực hiện thông qua proxy và không phải thông qua sửa đổi mã của bạn.

Như trong AspectJ, bạn có thể sử dụng dệt thời gian tải trong SpringAOP. Bạn có thể hưởng lợi từ tính năng này vào mùa xuân được triển khai với một tác nhân và các cấu hình đặc biệt @EnabledLoadWeavinghoặc bằng XML. Bạn có thể sử dụng không gian tên làm ví dụ. Tuy nhiên, trong Spring AOP, bạn không thể chặn tất cả các trường hợp. Ví dụ: newlệnh không được hỗ trợ trong Spring AOP.

Tuy nhiên, trong Spring AOP, bạn có thể hưởng lợi từ việc sử dụng AspectJ thông qua việc sử dụng aspectofphương thức nhà máy trong bean cấu hình mùa xuân.

Vì lý do Spring AOP về cơ bản là một proxy được tạo từ container, vì vậy bạn chỉ có thể sử dụng AOP cho đậu mùa xuân. Trong khi với AspectJ, bạn có thể sử dụng khía cạnh trong tất cả các loại đậu của mình. Một điểm so sánh khác là gỡ lỗi và dự đoán hành vi mã. Với spring AOP, công việc được tạo trước tất cả từ trình biên dịch Java và các khía cạnh là một cách rất hay để tạo proxy cho bean Spring của bạn. Trong AspectJ nếu bạn sửa đổi mã, bạn cần biên dịch nhiều hơn và để hiểu các khía cạnh của bạn được dệt ở đâu có thể khó khăn. Ngay cả việc tắt chế độ dệt vào mùa xuân cũng đơn giản hơn: với mùa xuân, bạn loại bỏ khía cạnh khỏi cấu hình của mình, khởi động lại và nó hoạt động. Trong AspectJ, bạn phải biên dịch lại mã!

Trong dệt thời gian tải, AspectJ linh hoạt hơn Spring vì Spring không hỗ trợ tất cả các tùy chọn của AspectJ. Nhưng theo ý kiến ​​của tôi Nếu bạn muốn thay đổi quy trình tạo hạt, cách tốt hơn là quản lý thông tin đăng nhập tùy chỉnh trong nhà máy và không phải dệt theo thời gian tải một khía cạnh thay đổi hành vi của nhà điều hành mới của bạn.

Tôi hy vọng rằng toàn cảnh này của AspectJ và Spring AOP sẽ giúp bạn hiểu được sự khác biệt của hai loại thuốc

Điều quan trọng là phải xem xét liệu các khía cạnh của bạn sẽ là nhiệm vụ quan trọng và nơi mã của bạn đang được triển khai. Spring AOP sẽ có nghĩa là bạn đang dựa vào dệt thời gian tải. Điều này có thể không dệt được và theo kinh nghiệm của tôi có nghĩa là các lỗi đã ghi có thể tồn tại nhưng sẽ không ngăn ứng dụng chạy mà không có mã khía cạnh [Tôi sẽ thêm cảnh báo rằng có thể cấu hình nó theo cách mà đây không phải là trường hợp; nhưng cá nhân tôi không biết điều đó ]. Biên dịch thời gian dệt tránh điều này.

Ngoài ra, nếu bạn sử dụng AspectJ kết hợp với plugin facj-maven thì bạn có thể chạy thử nghiệm đơn vị đối với các khía cạnh của bạn trong môi trường CI và tin tưởng rằng các tạo phẩm được xây dựng được kiểm tra và dệt chính xác. Mặc dù bạn chắc chắn có thể viết các bài kiểm tra đơn vị do Spring điều khiển, bạn vẫn không có gì đảm bảo rằng mã được triển khai sẽ là mã đã được kiểm tra nếu LTW thất bại.

Một cân nhắc khác là liệu bạn có đang lưu trữ ứng dụng trong môi trường mà bạn có thể theo dõi trực tiếp sự thành công hay thất bại của việc khởi động máy chủ / ứng dụng hay không, liệu ứng dụng của bạn có được triển khai trong một môi trường không nằm dưới sự giám sát của bạn hay không được lưu trữ bởi một khách hàng]. Một lần nữa, điều này sẽ chỉ ra cách biên dịch thời gian dệt.

Năm năm trước, tôi rất thích Spring cấu hình AOP vì lý do đơn giản là nó dễ làm việc hơn và ít có khả năng nhai IDE của tôi. Tuy nhiên, khi sức mạnh tính toán và bộ nhớ khả dụng tăng lên, điều này đã trở thành vấn đề ít hơn và CTW với plugin facj-maven đã trở thành một lựa chọn tốt hơn trong môi trường làm việc của tôi dựa trên những lý do tôi đã nêu ở trên.

Bài viết này cũng có một lời giải thích tốt về chủ đề này.

Spring AOP và AspectJ có những mục tiêu khác nhau.

Spring AOP nhằm mục đích cung cấp một triển khai AOP đơn giản trên Spring IoC để giải quyết các vấn đề phổ biến nhất mà các lập trình viên gặp phải.

Mặt khác, AspectJ là công nghệ AOP ban đầu nhằm cung cấp giải pháp AOP hoàn chỉnh.

So với AOP, AspectJ không cần tăng cường lớp mục tiêu tại thời gian biên dịch. Thay vào đó, nó tạo ra một lớp proxy cho lớp đích trong thời gian chạy, nó thực hiện cùng một giao diện với lớp đích hoặc là một lớp con của lớp đích.

Tóm lại, một thể hiện của một lớp proxy có thể được sử dụng như một thể hiện của lớp đích. Nhìn chung, khung AOP được tăng cường thời gian biên dịch có lợi thế hơn về hiệu năng, vì khung AOP được tăng cường thời gian chạy yêu cầu cải tiến động mỗi khi chạy.