مشروع الحذاء الربيعي اعتراضات ومرشحات عملية

1. التقاطعات والمرشحات

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

1. الفلتر يعتمد على حاويات servlet وهو جزء من مواصفات servlet. الاعتراضات موجودة بشكل مستقل ويمكن استخدامها تحت أي ظرف من الظروف.

2. يتم الانتهاء من تنفيذ المرشح بواسطة رد اتصال حاوية Servlet ، وعادة ما يتم تنفيذ التقاطع من خلال وكيل ديناميكي.

3. تتم إدارة دورة حياة المرشح بواسطة حاوية Servlet ، بينما يمكن إدارة التقاطع من خلال حاويات IOC. لذلك ، يمكن الحصول على حالات الفاصوليا الأخرى من خلال الحقن وطرق أخرى ، لذلك سيكون أكثر ملاءمة للاستخدام.

2. تصفية تكوين

الآن نستخدم المرشحات لتحقيق وظيفة تسجيل وقت تنفيذ الطلبات ، والتي يتم تنفيذها على النحو التالي:

 الطبقة العامة logcostfilter تنفذ filter {Override public void init (filterConfig filterConfig) يلقي servletexception {} @override void dofilter (servletrequest servletrequest ، servletresponseponseponse ، filterchain filterchain) throws ioexception ، servettimiStimImImicling () filterchain.dofilter (servletRequest ، servletResponse) ؛ system.out.println ("تنفيذ التكلفة ="+(system.currentTimeMillis ()-start)) ؛ } Override public void Dorner () {}}

منطق هذا الرمز بسيط نسبيًا ، وهو تسجيل الطابع الزمني قبل تنفيذ الطريقة ، ثم أكمل تنفيذ الطلب من خلال سلسلة المرشح ، وحساب وقت التنفيذ بين النتائج التي تم إرجاعها. الشيء الرئيسي هنا هو أن هذا الفصل يجب أن يرث فئة المرشح. هذا هو مواصفات servlet ، والتي لا تختلف عن مشاريع الويب السابقة. ومع ذلك ، مع فئة المرشح ، يمكن تكوين مشاريع الويب السابقة في web.xml ، لكن مشروع Boot Spring لا يحتوي على ملف web.xml ، إذن كيفية تكوينه؟ في Boot Spring ، نحتاج إلى FilterRegistrationBean لإكمال التكوين. عملية التنفيذ هي كما يلي:

 ConfigurationPublic Class FilterConfig {bean publicistrationbean registrationFilter () {filterRegistrationBean registration = filterregistrationBean () جديد ؛ التسجيل. registration.addurlpatterns ("/*") ؛ التسجيل. التسجيل. تسجيل العودة ؛ }}

تم الانتهاء من هذا التكوين. تتضمن الخيارات التي يجب تكوينها بشكل أساسي إنشاء إنشاء فئة المرشح ، ثم تحديد نمط المطابقة لعنوان URL ، وتعيين اسم المرشح وترتيب التنفيذ. هذه العملية لا تختلف في الواقع عن التكوين في web.xml ، ولكن النموذج مختلف تمامًا. الآن يمكننا بدء الخادم للوصول إلى أي عنوان URL:

يمكنك أن ترى أن التكوين أعلاه قد بدأ سريانه. بالإضافة إلى التكوين من خلال FilterRegistrationBean ، هناك أيضًا طريقة أكثر مباشرة ، يمكن إكمالها مباشرة من خلال التعليقات التوضيحية:

 webFfilter (urlpatterns = "/*" ، fletername = "logfilter2") فئة عامة logcostfilter2 تنفذ filter {Override public void init (filterConfig filterConfig) servletexception {} override public void dofilter (servletrequest servletresponse ، filterchain) يلقي ioException ، servleTexception {long start = system.currentTimeMillis () ؛ filterchain.dofilter (servletRequest ، servletResponse) ؛ System.out.println ("logFilter2 تنفيذ التكلفة =" + (system.currentTimeMillis () - start)) ؛ } Override public void Dorner () {}}

هنا يمكنك تكوينه مباشرة مع WebFilter. وبالمثل ، يمكنك تعيين وضع مطابقة عنوان URL واسم المرشح وما إلى ذلك بالإضافة إلى هذا التعليق التوضيحي ، نحتاج أيضًا إلى إضافة تعليق توضيحي آخر إلى فئة التكوين: servletcomponetscan ، مع تحديد الحزمة الممسوحة ضوئيًا.

 @springbootapplication@mapperscan ("com.pandy.blog.dao")@servletcomponentscan ("com.pandy.blog.filters") تطبيق الفئة العامة {public static void main (string [] args) استثناء {springapplication.run (application.class ، args) ؛ }}

الآن ، دعنا نزور أي عنوان URL مرة أخرى:

كما ترون ، فإن كلا المرشحين الذين قمنا بتكوينه قد أسرّا. سيجد القراء الدقيقون أننا لا نحدد ترتيب تنفيذ المرشح الثاني ، ولكن التنفيذ قبل المرشح الأول. يجب أن يفسر هنا أن شرح التعليق التوضيحي لـ webFilter لا يحدد سمة ترتيب التنفيذ. يعتمد ترتيب التنفيذ الخاص به على اسم المرشح ويتم ترتيبه بترتيب عكسي بناءً على الترتيب الأبجدي لاسم فئة المرشح (لاحظ أنه ليس اسم المرشح المكون). تكون أولوية المرشح المحددة بواسطة WebFilter أعلى من المرشح الذي تم تكوينه بواسطة FilterRegistrationBean. يمكن للأصدقاء المهتمين تجربة من تلقاء أنفسهم.

3. تكوين التقاطع

لقد قدمنا ​​بالفعل طريقة تكوين المرشح أعلاه. بعد ذلك ، دعونا نلقي نظرة على كيفية تكوين اعتراض. نستخدم اعتراضًا لتنفيذ نفس الوظيفة أعلاه ، وتسجيل وقت تنفيذ الطلب. أولاً ننفذ فئة التقاطع:

 الفئة العامة logcostinterceptor تنفذ معالج {long start = system.currentTimeMillis () ؛ Override public boolean prehandle (httpservletrequest httpservletrequest ، httpservletresponse httpservletresponse ، كائن O) يلقي استثناء {start = system.currenttimeMillis () ؛ العودة صحيح. } Override public void postthandle (httpservletrequest httpservletrequest ، httpservletresponse httpservletresponse ، object o ، modelandview) يلقي الاستثناء {system.out.println ("interceptor cost ="+(system.currentimeMillis) } Override public void eftercompletion (httpservletrequest httpservletrequest ، httpservletresponse httpservletrespons

هنا نحتاج إلى تنفيذ واجهة المعالج. تتضمن هذه الواجهة ثلاث طرق. يتم تنفيذ prehandle قبل تنفيذ الطلب ، ويتم تنفيذ Postthandler بعد تنفيذ الطلب ، ولكن سيتم تنفيذها فقط عندما تعود طريقة prehandle بشكل صحيح. يتم تنفيذ Aftercompletion بعد الانتهاء من عرض العرض. Prehandle يحتاج أيضا إلى العودة الحقيقية. عادة ما تستخدم هذه الطريقة لتنظيف الموارد والمهام الأخرى. بالإضافة إلى تنفيذ الواجهة أعلاه ، نحتاج أيضًا إلى تكوينه:

 ConfigurationPublic Class interceptorConfig يمتد webmvcConfigureRadapter {Override public void addInterceptors (interceptorregistry registry) {registry.adDinterceptor (new logcostinterceptor ()). addathpatterns ("/**") ؛ Super.AddInterceptors (السجل) ؛ }}

هنا ورثنا webmvcconfigureRadapter. كان ينبغي على الأصدقاء الذين قرأوا المقالات السابقة أن يروا هذا الفصل. لقد استخدمنا هذا الفئة عند تكوين دليل الموارد الثابت. هنا قمنا بإعادة كتابة طريقة AddInterceptors لتكوين التقاطع. هناك نوعان من عناصر التكوين الرئيسية: أحدهما هو تحديد التقاطع والآخر هو تحديد عنوان URL للاعتراض. الآن نبدأ النظام ونصل إلى أي عنوان URL:

كما ترون ، حققنا نفس الوظيفة من خلال التقاطع. ومع ذلك ، تجدر الإشارة هنا إلى أن هذا التنفيذ يمثل مشكلة في الواقع ، لأن Prehandle و Posthandle هما طريقان ، لذلك يتعين علينا تعيين بداية متغيرة مشتركة لتخزين قيمة البداية ، ولكن هذا سيكون له مشاكل سلامة مؤشرات الترابط. بالطبع ، يمكننا حل هذه المشكلة من خلال طرق أخرى ، مثل ThreadLocal ، والتي يمكن حلها بشكل جيد ، ويمكن للطلاب المهتمين بتنفيذها بأنفسهم. ومع ذلك ، من خلال هذا ، يمكننا في الواقع أن نرى أنه على الرغم من أن المقاطعات أفضل من المرشحات في العديد من السيناريوهات ، في هذا السيناريو ، تكون المرشحات أبسط من المعترضات.

4. ملخص

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