تطبيق AOP

Question

لقد كنت أستخدم بعض الحلول الأساسية لأسلوب AOP للمخاوف الشاملة مثل الأمان والتسجيل والتحقق من الصحة وما إلى ذلك.لقد شمل الحل الخاص بي قلعة وندسور والوكيل الديناميكي.لقد سلكت هذا الطريق لأنه يمكنني تطبيق كل شيء باستخدام DSL المستند إلى Boo والحفاظ على الكود الخاص بي نظيفًا من السمات.قيل لي في عطلة نهاية الأسبوع لإلقاء نظرة على بوستشارب كما من المفترض أن يكون الحل "الأفضل".لقد ألقيت نظرة سريعة على PostSharp، لكن تم تأجيلي بسبب استخدام السمات.

هل جرب أحد كلا الحلين ويرغب في مشاركة تجاربه؟

Answer 1

لقد نظرت إلى Castle-windsor لفترة قصيرة فقط (حتى الآن) لذا لا يمكنني التعليق على ذلك ولكني استخدمت postharp.

يعمل Postsharp عن طريق النسيج في وقت الترجمة.إنه يعلن عن خطوة ما بعد الترجمة إلى الإصدار الخاص بك حيث يقوم بتعديل التعليمات البرمجية الخاصة بك.يتم تجميع الكود كما لو كنت قد قمت للتو ببرمجة الاهتمامات الشاملة في الكود الخاص بك.يعد هذا أكثر أداءً قليلاً من النسيج في وقت التشغيل وبسبب استخدام السمات، فإن Postsharp سهل الاستخدام للغاية.أعتقد أن استخدام سمات AOP لا يمثل مشكلة مثل استخدامه لـ DI.ولكن هذا مجرد ذوقي الشخصي.

لكن...

إذا كنت تستخدم القلعة بالفعل لحقن التبعية، فلا أرى سببًا وجيهًا لعدم استخدامها أيضًا لأشياء AOP.أعتقد أنه على الرغم من أن AOP في وقت التشغيل أبطأ قليلاً منه في وقت الترجمة، إلا أنه أكثر قوة أيضًا.AOP و DI هما في رأيي مفهومان مرتبطان لذا أعتقد أنه من الجيد استخدام إطار عمل واحد لكليهما.لذلك ربما سألقي نظرة على أشياء القلعة مرة أخرى في المشروع التالي الذي أحتاج إليه AOP.

Answer 2

زوجان من المشاكل البسيطة مع PostSharp ...

إحدى المشكلات التي أواجهها مع PostSharp هي أنه أثناء استخدام asp.net، يتم "إخراج" أرقام الأسطر لرسائل الاستثناء من خلال عدد تعليمات IL التي تم حقنها في التجميعات بواسطة PostSharp حيث لم يتم حقن PDBs أيضًا :-).

وأيضًا، بدون تجميعات PostSharp المتوفرة في وقت التشغيل، تحدث أخطاء في وقت التشغيل.باستخدام Windsor، يمكن إيقاف تشغيل المقاطع المتقاطعة في وقت لاحق دون إعادة ترجمة التعليمات البرمجية.

(آمل أن يكون هذا منطقيا)