استخدم التعليقات التوضيحية لبناء حاويات IOC
استخدم التعليقات التوضيحية لتسجيل الفاصوليا مع حاويات الزنبرك. تحتاج إلى التسجيل في ApplicationContext.xml <Context: Component-Scan Base-Package = "Pagkage1 [، Pagkage2 ، ... ، Pagkagen]"/>.
على سبيل المثال: حدد حزمة في الحزمة الأساسية
<السياق: مكون المسح الضوئي package = "cn.gacl.java"/>
يشير إلى أنه إذا كان لدى الفئة تعليقًا محددًا [@component/@ropository/@service/@controller] في حزمة cn.gacl.java وحقائبه الفرعية ، سيتم تسجيل هذا الكائن في حاوية الربيع كحبة. يمكنك أيضًا تحديد حزم متعددة في <Context: Component-Scan Base-Package = ""/> ، مثل:
<السياق: مكون الفسيلة القاعدة ـ "cn.gacl.dao.impl ، cn.gacl.service.impl ، cn.gacl.action"/>
يتم فصل حزم متعددة عن طريق الفواصل.
1. component
@عنصر
إنه شكل شائع لجميع المكونات المدارة في الربيع. يمكن وضع التعليق التوضيحي component على رأس الفصل ، ولا ينصح component.
2. controller
Controller يتوافق مع حبة طبقة العرض ، أي العمل ، على سبيل المثال:
ControllerSCOPE ("النموذج الأولي") تمتد عامل مستخدم الفئة العامة إلى BASEACTION <SERSING> {...}بعد استخدام التعليق التوضيحي Controller لتحديد معامل المستخدم ، فهذا يعني أن معامل المستخدم يجب تسليمه إلى حاوية الربيع للإدارة. سيكون هناك إجراء يسمى "عامل المستخدم" في حاوية الربيع. تم أخذ هذا الاسم بناءً على اسم فئة المستخدم. ملاحظة: إذا لم يحدد Controller قيمته 【Controller】 ، فإن اسم الفاصوليا الافتراضي هو صغير في الحرف الأول من اسم الفصل. إذا قمت بتحديد القيمة 【Controller (value = "useraction")】 أو 【Controller ("Useraction")】 ، ثم استخدم القيمة كاسم للفول.
يستخدم UserAction هنا أيضًا التعليق التوضيحي SSCOPE. SSCOPE ("النموذج الأولي") يعني أن نطاق الإجراء يتم الإعلان عنه كنموذج أولي. يمكنك استخدام Scope = "النموذج الأولي" للحاوية للتأكد من أن كل طلب لديه إجراء منفصل للتعامل معه ، وتجنب مشكلات سلامة مؤشرات الترابط في الدعامات. الربيع النطاق الافتراضي هو وضع Singleton (Scope = "Singleton") ، والذي سيقوم فقط بإنشاء كائن عمل. كل وصول هو نفس كائن الإجراء. البيانات ليست آمنة. يتطلب Struts2 أن كل وصول يتوافق مع إجراء مختلف. يمكن أن يضمن Scope = "النموذج الأولي" إنشاء كائن عمل عند وجود طلب.
3. @ الخدمة
Service يتوافق مع حبة طبقة الخدمة ، على سبيل المثال:
service ("uservervice") فئة عامة orseverserviceImpl تنفذ المستخدمين {.......}يخبر Service ("UserviserVice") SPRING أنه عندما يريد Spring إنشاء مثيل من sterveserviceImpl ، يجب أن يطلق على اسم الفول "Usservice". وبهذه الطريقة ، عندما يحتاج الإجراء إلى استخدام مثيل لـ UserviceRviceImpl ، يمكن حقن "مستخدمي المستخدمين" الذي تم إنشاؤه بواسطة Spring إلى العمل: في العمل ، تحتاج فقط إلى إعلان متغير يسمى "Userverservice" لتلقي "uservervice" التي تم حقنها بحلول الربيع. الرمز المحدد كما يلي:
// حقن UserServiceResource (name = "UserService") usterverservice من القطاع الخاص ؛
ملاحظة: يجب أن يكون نوع متغير "uservervice" المعلن في الإجراء هو "مستخدمين" أو "فئة الأم" ، وإلا فإنه لا يمكن حقنه بسبب الأنواع غير المتسقة. نظرًا لأن متغير "userverservice" المعلن في الإجراء يستخدم شرح @Resource ويشير إلى اسمه = "UserService" ، وهو ما يعادل إخبار الربيع بأنني أريد إنشاء "مستخدمين". سوف يساعدني الربيع في إنشاء مثيل له بسرعة ، ثم أعطه لي. عندما يرى Spring شرح @Resource على متغير Userversevice ، وفقًا لسمة الاسم المحددة ، يمكنك أن تعرف أن مثيلًا لـ UserviceRviceImpl يجب استخدامه في الإجراء. في هذا الوقت ، ستقوم Spring بضخ مثيل UserviceRviceImpl الذي يطلق عليه "UsperService" في متغير "UsperService" في الإجراء لمساعدة الإجراء على إكمال إنشاء مستخدمي المستخدمين ، لذلك في الإجراء ، لا توجد حاجة لاستخدام "UserServiceervice = new orperServiceImpl () ؛" هذه هي الطريقة الأكثر بدائية لإنشاء مستخدمي المستخدمين.
إذا لم يكن هناك ربيع ، عندما يحتاج الإجراء إلى استخدام UsperServiceImpl ، فيجب عليك إنشاء كائن مثيل بنشاط من خلال "UsperService UsperService = New UserviceRviceImpl () ؛". ومع ذلك ، بعد استخدام الربيع ، عندما يريد Action استخدام UsperServiceImpl ، لا يتعين عليك إنشاء مثيل فعلي لـ UserviceRviceImpl. تم إنشاء مثيل userviceiMpl إلى الربيع. يمنح Spring مثيل AssorerviceImpl الذي تم إنشاؤه إلى هذا الإجراء ، ويمكنك استخدامه مباشرة بعد الحصول على الإجراء.
يمكن استخدام الإجراء فورًا بعد إنشاء مثيل UserviceServiceImpl بنشاط ، ولكنه ينتظر بشكل سلبي لإنشاء Spring لإنشاء مثيل UsperServiceImpl قبل حقنه في العمل.
هذا يدل على أن "التحكم" في الإجراء على فئة "UserviceRviceImpl" قد تم "عكس". اتضح أن المبادرة في يدي. لا بد لي من استخدام مثيل فئة "userviceRviceImpl". يمكنني أخذ المبادرة لاستخدامها على الفور. لكن الآن لا يمكنني أخذ المبادرة إلى مثيلات جديدة من مثيل فئة "UserviceRviceImpl". تم أخذ قوة مثيل فئة "userviceRviceImpl" الجديد بحلول الربيع. يمكن فقط لـ Spring أن تكون مثيلًا جديدًا لمثيل "UserviceRviceImpl" ، ويمكن أن ينتظر العمل فقط لإنشاء فئة "مستخدمين" بعد مثيل فئة RVICEIMPL "، يرجى" الربيع "يعطيه مثيل" تم إنشاؤه "لفئة" UsperServiceImpl "حتى يتمكن من استخدام" الاستخدام ". UserviceImpl ، لذلك ينشئ تبعية على userviceimpl.
4. @ مستودع
repository يتوافق مع حبة طبقة الوصول إلى البيانات ، على سبيل المثال:
repository (value = "userDao") فئة عامة userDaoImpl تمتد على أساسها <Sether> {...........}يخبر التعليق التوضيحي repository (value = "userdao") Spring أن يدع Spring إنشاء مثيل userDaoImpl يسمى "userDao".
عندما تحتاج الخدمة إلى استخدام مثيل userDaoImpl المسمى "userDao" الذي تم إنشاؤه بحلول الربيع ، يمكنك استخدام التعليق التوضيحي Resource (name = "userDao") لإخبار الربيع ، ويمكن لـ Spring ضخ UserDao الذي تم إنشاؤه في الخدمة.
// حقن UserDao ، وعند إخراج المستخدم المحدد من قاعدة البيانات وفقًا لمعرف المستخدم ، تحتاج إلى استخدام @name = "userDao") على أساس خاص <Sether> userDao ؛
يتم استخدام Resource و Autowired و QAlifier لجميع الكائنات. من بينها ، يمكن حقن Resource بالاسم أو النوع ، لا يمكن حقن Autowired إلا في النوع ، ولا يمكن حقن Qualifier إلا بالاسم.
لكن لديهم بعض الاختلافات الدقيقة:
1. يتم حقن Resource و Qualifier تلقائيًا بواسطة ByName افتراضيًا ، ويتم حقن Autowired تلقائيًا بواسطة Bytype افتراضيًا.
2. Resource لديه خصائصان أكثر أهمية ، الاسم والنوع. إذا تم استخدام سمة الاسم ، يتم استخدام سياسة الحقن التلقائي لتسمية BYN. عند استخدام سمة النوع ، يتم استخدام سياسة الحقن التلقائي BYTYPE.
3. Resources هو تعليق توضيحي قدمه JDK ، في حين أن Autowired هو شرح قدمه الربيع.
يمكنك علاج Resource كرئيس لـ @Qalifier ، هاها. لدي ما لديك ، ولدي ما ليس لديك ، ولدي أيضًا ~
يتم استخدام Resource و Autowired و QAlifier لجميع الكائنات. من بينها ، يمكن حقن Resource بالاسم أو النوع ، لا يمكن حقن Autowired إلا في النوع ، ولا يمكن حقن Qualifier إلا بالاسم.
لكن لديهم بعض الاختلافات الدقيقة:
1. يتم حقن Resource و Qualifier تلقائيًا بواسطة ByName افتراضيًا ، ويتم حقن Autowired تلقائيًا بواسطة Bytype افتراضيًا.
2. Resource لديه خصائصان أكثر أهمية ، الاسم والنوع. إذا تم استخدام سمة الاسم ، يتم استخدام سياسة الحقن التلقائي لتسمية BYN. عند استخدام سمة النوع ، يتم استخدام سياسة الحقن التلقائي BYTYPE.
3. Resources هو تعليق توضيحي قدمه JDK ، في حين أن Autowired هو شرح قدمه الربيع.
يمكنك علاج Resource كرئيس لـ @Qalifier ، هاها. لدي ما لديك ، ولدي ما ليس لديك ، ولدي أيضًا ~
إن التعليقات التوضيحية الربيعية المذكورة أعلاه هي طريقة استخدام التعليقات التوضيحية لبناء حاويات IOC هي كل المحتوى الذي شاركته معك. آمل أن تتمكن من إعطائك مرجعًا وآمل أن تتمكن من دعم wulin.com أكثر.