تحليل متعمق لرسم خرائط للجمعية الفردية في إطار السبات في Java

كإطار ORM ، يجب أن تلبي السبات أيضًا احتياجاتنا لتنفيذ الارتباط بين الجداول. تطبيق السبات في طريقة الارتباط أمر بسيط للغاية. دعونا نلقي نظرة على نهج فردي:
بدون مزيد من اللغط ، دعنا فقط نحمل الرمز:
فئتان كيانان ، Tuser و Tapport:

 الطبقة العامة tuser تنفذ مسلسل {private static final long serialversionuid = 1l ؛ معرف int الخاص ؛ عصر INT الخاص ؛ اسم السلسلة الخاصة ؛ Private Tpassport Passport ؛ . معرف int الخاص ؛ سلسلة خاصة. انتهاء الصلاحية الخاصة ؛ مستخدم Tuser الخاص ؛ // حذف GET/SET METLEST}

دعونا نلقي نظرة على الاختلافات بين ملفات التعيين:

 <hibernate-mapping package = "org.hibernate.tutorial.domain4"> <class name = "tuser" table = "user4"> <id name = "id" column = "id"> <generator/> </id> <property name = "name" type = "java.lang.string" column = column = "Age"/> <name-to-One = "passport" cascade = "all" Outer-Join = "True"/> </slass> </hibernate mapping>

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

 <hibernate-mapping package = "org.hibernate.tutorial.domain4"> <class name = "tpassport" table = "passport4"> <id name = "ID" name = "expiry" type = "java.lang.integer" column = "Expiry"/> <name On-One = "User"

نحن هنا نركز على قيمة فئة المولد. إنه يشير إلى المفتاح الخارجي المرجعي للأجانب ، والذي يتم تحديده بواسطة Param ، مما يشير إلى معرف فئة المستخدم المرجعية. هناك خاصية مقيدة إضافية في العلامة الفردية ، والتي تخبر Hibernate أن هناك قيود مفتاح خارجي في الفئة الحالية ، أي أن معرف الفئة الحالية يتم إنشاؤه بناءً على معرف tuser.
دعونا نحمل فئة الاختبار مباشرة. هذه المرة ، لم تستخدم فئة الاختبار Junit ولكنها جاءت مباشرة مع الطريقة الرئيسية:

 public static void main (string [] args) {configuration cfg = new configuration (). configure () ؛ SessionFactory SessionFactory = cfg.buildSessionFactory () ؛ جلسة الجلسة = sessionfactory.opensession () ؛ Session.begintransaction () ؛ مستخدم tuser = new tuser () ؛ user.setage (20) ؛ user.setName ("Shuntest") ؛ TPAPSPORT PASTPORT = New TPAPSPORT () ؛ passport.setexpiry (20) ؛ Passport.SetSerial ("123123123") ؛ passport.setuser (المستخدم) ؛ user.setPassport (جواز السفر) ؛ Session.save (user) ؛ session.getTransaction (). الالتزام () ؛ }

الكود بسيط للغاية ، لذلك لن أتحدث عنه. دعونا نلقي نظرة عليه هنا بشكل أساسي:

 Session.save (user) ؛

لماذا ندعو واحدة فقط حفظ هنا؟ والسبب هو أن خاصية Cascade في ملف تعيين Tuser الخاص بنا يتم تعيينها على الجميع ، مما يعني أنه عندما نقوم بحفظ ، تحديث ، إلخ ، على tuser ، ستقوم Tpassport أيضًا بإجراء العمليات المقابلة ، لذلك لا نحتاج إلى كتابة Session.save (جواز السفر). نرى الخلفية:

 السبات: إدراج في user4 (الاسم ، العمر) القيم (؟ ،؟) السبات: إدراج في Passport4 (Serial ، Expiry ، id) قيم (؟ ،؟ ،؟)

السبات: إنه يطبع بيانين ، مما يثبت أن السبات قد أنجز هذا العمل بالنسبة لنا.


لنأخذ فئة اختبار أخرى واختبار الاستعلام:

 public static void main (string [] args) {configuration cfg = new configuration (). configure () ؛ SessionFactory SessionFactory = cfg.buildSessionFactory () ؛ جلسة الجلسة = sessionfactory.opensession () ؛ tuser user = (tuser) session.load (tuser.class ، integer (3)) ؛ System.out.println (user.getName ()+":"+user.getPassport (). getSerial ()) ؛ }

هنا نستفسر عن فئة Tuser والحصول على كائن Tpassport.
يمكننا أن نرى أن بيان SQL لـ Hibernate هو:
نسخة الكود كما يلي:
السبات:
حدد tuser0_.id as id0_1_ ، tuser0_.name as name0_1_ ، tuser0_.age as Age0_1_ ، tpassport1_.id as id1_0_ ، tpassport1_.serial as serial1_0_ ، tpassport1_.expiry as expiry1_0_ from user4 tuser0_ on outer_ on outer_ on on tuser0_.id = tpassport1_.id حيث tuser0_.id =؟

نرى اليسار الخارجي الانضمام إلى البيان ، لأننا وضعنا OUTER-JOIN = "TRUE" في شخص واحد. نحاول تغييره إلى خطأ. بيان SQL كما يلي:
نسخة الكود كما يلي:
السبات:
حدد tuser0_.id as id0_0_ ، tuser0_.name as name0_0_ ، tuser0_.age as Age0_0_ from user4 tuser0_ where tuser0_.id =؟ hibernate:
حدد tpassport0_.id as id1_0_ ، tpassport0_.serial as serial1_0_ ، tpassport0_.expiry as Expiry1_0_ من passport4 tpassport0_ أين tpassport0_.id =؟

الآن قمنا بتقسيمه إلى عنصرين للتحقق منه ، ثم وجدته بناءً على المعرف الموجود في العنصر الأول ثم إلى العنصر الثاني.

ربما سيسأل الكثير من الناس عن سبب عدم استخدام Tpassport لمعرفة Tusers أثناء الاختبار. في الواقع ، من الممكن أيضًا ، لأنها علاقة فردية ، وكل من يتحقق سيكون هو نفسه.

جمعية المفتاح الخارجية
الآن دعونا نلقي نظرة على الجمعيات الفردية التي تجعل الجمعيات من خلال المفاتيح الأجنبية.
لا يزال هو نفسه المثال: لقد كتبنا فئتين كيان ، Tgroup و Tuser

 الطبقة العامة tgroup تنفذ serializable {private Static Final Long SerialVersionuid = 1L ؛ معرف int الخاص ؛ اسم السلسلة الخاصة ؛ مستخدم Tuser الخاص ؛ . معرف int الخاص ؛ عصر INT الخاص ؛ اسم السلسلة الخاصة ؛ مجموعة Tgroup الخاصة ؛ // حذف GET/SET METLEST}

بعد انتهاء فئة الكيان ، دعونا نلقي نظرة على ملف التعيين:

 <hibernate-mapping package = "org.hibernate.tutorial.domain5"> <class name = "tuser" table = "user5"> <id name = "id" column = "id"> <generator/> </id> <property name = "name" type = "java.lang.string" column = column = "Age"/> <to to one name = "group" column = "group_id" quientive = "true"/> </slass> </- hibernate mapping>

نرى هنا أن العلامة العديدة إلى واحدة تستخدم بدلاً من واحد إلى واحد. لماذا؟
لم أهتم به كثيرًا عندما استخدمته من قبل. على أي حال ، يمكنني استخدامه. ولكن بعد قراءة كتاب Xia Xin هذه المرة ، فهمت أخيرًا أنه في الواقع ، فإن طريقة الارتباط هذه من خلال المفاتيح الأجنبية هي مجرد وسيلة خاصة للعديد من إلى واحد. لقد حصرناها من خلال فريدة = "صواب" أنه يجب أن يكون لها واحدة فقط ، أي ارتباط واحد إلى واحد.
بعد ذلك ، دعونا نلقي نظرة على ملف تعيين Tgroup:

 <hibernate-mapping package = "org.hibernate.tutorial.domain5"> <class name = "tgroup" table = "group5"> <id name = "id" column = "id"> <generator/> </id> <property name = "name" type = "java.lang.string" column = </hibernate mapping>

هنا ، لاحظ أننا نستخدم فرديًا مرة أخرى ، مما يشير إلى أن الكيان الحالي وتوسير واحد إلى واحد. هنا ، لا نستخدم الكثير إلى واحد ، ولكن نحدد السمة في كيان Tuser لربط Tgroup الفئة الحالية. نحدد هنا أن Tuser يرتبط بـ Tuser من خلال سمات المجموعة. PROPERTIONAL-REF يحدد خاصية مشاركتها.
دعونا نلقي نظرة على فئة الاختبار أدناه:

 الفئة العامة hibernatetest {public static void main (string [] args) {configuration cfg = configuration (). configure () ؛ SessionFactory SessionFactory = cfg.buildSessionFactory () ؛ جلسة الجلسة = sessionfactory.opensession () ؛ Session.begintransaction () ؛ Tgroup Group = New Tgroup () ؛ group.setName ("TestGroup") ؛ مستخدم tuser = new tuser () ؛ user.setage (23) ؛ user.setName ("test") ؛ user.setGroup (Group) ؛ Group.SetUser (المستخدم) ؛ Session.Save (Group) ؛ Session.save (user) ؛ session.getTransaction (). الالتزام () ؛ session.close () ؛ }}

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

 Hibernate: insert في Group5 (الاسم) قيم (؟) السبات: إدراج في user5 (الاسم ، العمر ، group_id) قيم (،؟ ،؟)

هذا يعني أننا قمنا بتخزين قيمتين للكائن بشكل صحيح.

نكتب فئة اختبار إضافية للاستعلام:

 public static void main (string [] args) {configuration cfg = new configuration (). configure () ؛ SessionFactory SessionFactory = cfg.buildSessionFactory () ؛ جلسة الجلسة = sessionfactory.opensession () ؛ tuser user = (tuser) session.load (tuser.class ، integer (1)) ؛ System.out.println ("من المستخدم GET Group:"+user.getGroup (). getName ()) ؛ tgroup Group = (tgroup) session.load (tgroup.class ، عدد صحيح جديد (1)) ؛ System.out.println ("من مجموعة GET USER:" + group.getuser (). getName ()) ؛ session.close () ؛ }

يمكننا الحصول على النتيجة الصحيحة ، مما يدل على أنه يمكننا إخراج قيم الآخر من خلال كائنين ، لتحقيق هدفنا.
تعد Tgroup و Tuser المستخدمة في هذا المثال أمثلة فقط. في الواقع ، يتوافق المستخدمون في الحياة الحقيقية بشكل عام مع مجموعات متعددة.