Cách triển khai tốt nhất cho AOP trong .Net là gì? [đóng cửa]


83

Có rất nhiều triển khai AOP trong C #, VB.net. đây là một số Triển khai AOP:

Cách triển khai tốt nhất cho AOP trong .Net là gì? Những gì tôi nên sử dụng?


4
Sẽ rất hữu ích nếu bạn cung cấp các liên kết tới tất cả AOP, để người đọc tiết kiệm một chút thời gian với Google. Tôi hy vọng câu hỏi này / câu trả lời sẽ trở thành một tóm tắt tuyệt vời trong những lựa chọn AOP khác nhau trong .NET
Ian Ringrose

10
52 người đã bình chọn đây là một câu hỏi mang tính xây dựng. 5 bình chọn nó không mang tính xây dựng. Ai quyết định? Ít nhất thì người điều hành nên thay đổi hoặc định dạng lại câu hỏi, nhưng họ tốt hơn nên xem xét hầu hết ý kiến ​​của mọi người.
Lịch sử

2
@Revious Hoàn toàn đồng ý!
Legends

1
Thật là ngạc nhiên khi SO và mọi người phản đối những câu hỏi như thế này như OT. Một câu hỏi hữu ích như vậy và công nghệ để thảo luận và giúp cộng đồng chỉ đơn giản là bỏ phiếu xuống và đóng cửa nhưng một loạt những người theo phong cách cũ, những năm 80 bị mắc kẹt trong quá khứ. VẬY, thế giới đã thay đổi. Hoàn toàn có thể hiểu được rằng bạn muốn trợ giúp những câu hỏi cụ thể nhưng ít nhất hãy cung cấp một liên kết trong thẻ "đóng" của bạn để đăng những câu hỏi đó. Điều đó sẽ giúp ích rất nhiều và tránh được kiểu ngu ngốc này.
pixel

Câu trả lời:


45

Tôi nghĩ rằng Castle Dynamic Proxy là giải pháp được lựa chọn nếu đánh chặn động có thể đáp ứng nhu cầu của bạn. Khung công tác này được sử dụng nội bộ bởi rất nhiều khung công tác khác muốn cung cấp khả năng AOP. Thông thường, hầu hết các vùng chứa IoC hiện có đều cung cấp một số cơ chế đánh chặn động (Spring.NET, Castle Windsor, StructureMap, v.v.) Nếu bạn đã làm việc với vùng chứa IoC, có thể dễ dàng hơn khi xem xét những gì nó đề xuất.

Nếu đánh chặn động không thể giải quyết nhu cầu của bạn (dệt lớp kín, chặn cuộc gọi không ảo, v.v.), thì bạn chắc chắn muốn dệt tĩnh. PostSharp là tham chiếu trong miền này.

Lưu ý rằng nó cũng tồn tại Linfu , có thể được sử dụng để tận dụng cả thời trang AOP.


3
+1 về điều đó nếu bạn muốn thực hiện AOP thời gian chạy. 1 trên PostSharp nếu bạn muốn sau thời gian biên dịch AOP
Krzysztof Kozmic

Bất kỳ cập nhật về câu trả lời này? Hay điều này vẫn còn giá trị? Tôi đã đặc biệt tự hỏi như thế nào Spring.Aop so với Castle và PostSharp
Evren Kuzucuoglu

1
không may, PostSharp là một sản phẩm thương mại
Pixel

Postsharp là sản phẩm thương mại, không miễn phí. Vui lòng tư vấn bất cứ điều gì khác cho dệt tĩnh.
Shivam Sachan

@ShivamSachan Chỉ vì thứ gì đó miễn phí không làm cho nó tốt. Hầu hết AOP miễn phí trong .net đã chết với các bản cập nhật mới nhất cách đây 2-5 năm, PostSharp vẫn là tốt nhất trong lớp.
Ưu đãi

15

"Tốt nhất" là chủ quan.

Đầu tiên, hãy lập một danh sách các tính năng bạn cần, kiến ​​trúc của bạn, v.v. Sau đó, tìm kiếm các tùy chọn phù hợp với những gì bạn cần, mà không giới thiệu sự phức tạp không cần thiết. Ví dụ, một số được định hướng giao diện: của bạn hiện tại có định hướng giao diện không? Nếu không, PostSharp có thể là một lựa chọn tốt hơn (được đan vào các lớp gốc). Nhưng tất nhiên, PostSharp không thể được cấu hình trong thời gian chạy ... ngựa cho các khóa học.


bạn có thể định dạng lại những gì bạn đã nói như sau: "Tốt nhất là chủ quan, tôi sẽ vẽ một danh sách các chuyên gia và các đối thủ cho một số khuôn khổ này".
Lịch sử

11

Cách tốt nhất để lập trình hướng khía cạnh trong .NET là sử dụng các kỹ thuật thiết kế nổi tiếng. Ví dụ: bằng cách áp dụng các nguyên tắc SOLID, bạn có thể đạt được tính linh hoạt và tính mô đun mà bạn cần để cho phép thêm các mối quan tâm xuyên suốt. Nếu bạn có quyền thiết kế, bạn thậm chí sẽ có thể áp dụng hầu hết các mối quan tâm xuyên suốt mà không cần bất kỳ khuôn khổ nào. Thật là sai lầm khi nghĩ rằng OOP không phù hợp để thực hiện AOP.

Dưới đây là một số gợi ý:

  • Đừng phụ thuộc vào những trường hợp cụ thể mà hãy phụ thuộc vào những điều trừu tượng.
  • Đừng trộn lẫn các mối quan tâm xuyên suốt và logic kinh doanh trong cùng một lớp.
  • Thêm mối quan tâm xuyên suốt bằng cách bao bọc các lớp với logic nghiệp vụ trong các lớp thực hiện những mối quan tâm đó ( người trang trí ).
  • Tìm các tạo tác phổ biến trong thiết kế của bạn và lập mô hình chúng bằng nhau, tốt nhất là sử dụng cùng một kiểu trừu tượng. Hãy xem cái nàycái này chẳng hạn.

Khi bạn đã có sẵn những nội dung trừu tượng phù hợp, việc thêm những mối quan tâm xuyên suốt mới vào hệ thống chỉ là việc viết một lớp trang trí mới và gói nó xung quanh các triển khai phù hợp. Nếu sự trừu tượng là chung chung, bạn có thể bao bọc một trình trang trí duy nhất xung quanh một nhóm lớn các lớp (đó chính xác là những gì AOP nói về).

Mặc dù các kỹ thuật như proxy động và dệt mã có thể giúp làm việc dễ dàng hơn với một ứng dụng được thiết kế xấu, nhưng thực sự không có giải pháp thay thế nào cho thiết kế tốt. Sớm muộn gì bạn cũng sẽ bị bỏng. Điều này không có nghĩa là không nên sử dụng tính năng tạo proxy động và dệt mã. Nhưng nếu không có một thiết kế ứng dụng thích hợp thì ngay cả những kỹ thuật đó cũng sẽ hữu ích một chút.


AOP là cấp độ trừu tượng tiếp theo. Trên thực tế, chính hạn chế về tính kế thừa và thành phần dẫn đến AOP. Bạn đã thấy khối ngoại lệ Entlib chưa? Aspect gọn gàng hơn rất nhiều so với việc gọi khối chết tiệt đó cho mọi lệnh gọi vào cơ sở dữ liệu, chỉ để thử bắt-log-ném.
Sleeper Smith

2
Nếu bạn gói mọi cuộc gọi đến cơ sở dữ liệu của mình bằng một khối ngoại lệ, thì dù sao bạn cũng đang làm sai. Nó trở lại thiết kế tốt. Luôn luôn.
Steven

Vì vậy, thay vì bắt các ngoại lệ db cách nào là đúng?
OutOFTouch

2
@OutOFTouch: Hãy xem câu trả lời của câu hỏi SO này .
Steven

2
@SleeperSmith: mặc dù tôi không chắc "AOP là cấp độ trừu tượng tiếp theo" nghĩa là gì, nhưng tôi nghĩ rằng bạn không thể bảo trì các hệ thống lớn mà không sử dụng AOP. Tôi tin tưởng vào việc áp dụng AOP. Tuy nhiên, AOP là một mô hình; Không phải công cụ. Tôi đồng ý với giới hạn về tính kế thừa, nhưng đó không phải là giới hạn về thành phần dẫn đến AOP. Chính việc thiếu thiết kế thích hợp dẫn đến việc sử dụng các công cụ dệt mã và proxy động. Tôi áp dụng các mối quan tâm xuyên suốt bằng cách sử dụng trang trí. Đây là cách áp dụng AOP ưa thích của tôi.
Steven

5

Tôi không biết về điều tốt nhất, có rất nhiều khuôn khổ và không đủ giờ trong ngày để thử tất cả.

Tôi đã sử dụng PostSharp và rất ngạc nhiên khi bắt đầu với nó dễ dàng như thế nào.

Tôi cũng đã xem xét AOP với Castle Windsor và Spring.Net, cách tiếp cận là khác nhau (thời gian chạy so với thời gian biên dịch). Trộn AOP và IoC có vẻ hợp lý. Khi bạn không sử dụng một trong những khuôn khổ này, thì còn rất nhiều việc để bắt đầu nhưng đừng để điều đó cản trở bạn.

Đối với các dự án mới bây giờ tôi có thể sử dụng Castle Windsor, nhưng đó chủ yếu là vì tôi cũng muốn sử dụng IoC. Nếu tôi phải nhanh chóng triển khai AOP vào cơ sở mã hiện có, tôi sẽ sử dụng PostSharp.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.