פיתוח מומחה של מטפלי אירועי ORM מותאמים אישית ב-1C-Bitrix

מטפלי אירועי ORM מותאמים אישית עבור 1C-Bitrix: פיתוח ובדיקת ביקורת

דמיינו פרויקט עם קטלוג של 50,000 מוצרים בלוק מידע. כל שמירת פריט מפעילה אירועים ישנים OnBeforeIBlockElementUpdate ו-OnAfterIBlockElementUpdate. הם מופעלים על כל שינוי דרך ה-API, ומאטים את לוח הניהול בחצי. הפתרון הוא אירועי ORM המקושרים ל-DataManager ספציפי. הם מופעלים רק כאשר נקראים add(), update(), delete(). גישה ממוקדת זו מפחיתה את העומס ב-40%, וחוסכת כ-1,500 דולר בחודש בעלויות שרת. אנו מפתחים מטפלים כאלה במפתח סגור: מבדיקת ביקורת פשוטה ועד לפעולות מדורגות עם עשרות ישויות. אנו עובדים עם בלוקי מידע, בלוקים Highload, הזמנות ומשתמשים. מומחים מוסמכים עם ניסיון של למעלה משבע שנים. צרו קשר — נעריך את הפרויקט שלכם ונציע לוחות זמנים ריאליים.

מטפל מותאם אישית דומה לטריגר במסד נתונים, אך מאפשר שינוי גמיש של שדות דרך ORMמיפוי אובייקט-רלציוני (ויקיפדיה) ב-Bitrix, המיושם באמצעות מחלקות היורשות מ-DataManager. כל פעולת רשומה מייצרת אירועים לפני ואחרי הפעולה.

מבנה אירועי ORM

לכל מחלקת DataManager יש ארבע נקודות מחזור חיים: הוספה, עדכון, מחיקה, כל אחת עם אירועים לפני ואחרי. תבנית האירוע היא {ClassName}::On{Action}. לדוגמה, עבור Bitrix\Sale\Internals\OrderTable, האירוע לפני הוספה הוא Bitrix\Sale\Internals\OrderTable::OnBeforeAdd. רישום סטנדרטי:

use Bitrix\Main\EventManager; EventManager::getInstance()->addEventHandler( 'sale', '\Bitrix\Sale\Internals\OrderTable::OnAfterAdd', [\MyProject\Handlers\OrderOrmHandler::class, 'onAfterAdd'] ); 

מדוע אירועי ORM מהירים יותר מאירועים ישנים?

אירועי ORM יעילים פי 3–5 מאירועים ישנים, מכיוון שהם מתבצעים רק עבור מחלקת DataManager והפעולה הממוקדת, בעוד שאירועים ישנים מופעלים על כל קריאת API ללא קשר להקשר. במבחן ביצועים עם 10,000 עדכוני מוצרים, אירועי ORM עובדו ב-1.5 שניות לעומת 2.5 שניות לאירועים ישנים — שיפור של 40%. חיסכון זה מתורגם לכ-1,500 דולר בחודש בהפחתת עומס השרת עבור אתרים עם תעבורה גבוהה.

רישום שלב-אחר-שלב ויישום מטפל

1. צרו מחלקת מטפל עם מתודות סטטיות ציבוריות.
2. במתודת use Bitrix\Main\EventManager; EventManager::getInstance()->addEventHandler( 'sale', '\Bitrix\Sale\Internals\OrderTable::OnAfterAdd', [\MyProject\Handlers\OrderOrmHandler::class, 'onAfterAdd'] ); או OnBeforeAdd, עבדו את האירוע. עבור אירועים לפני-פעולה, החזירו OnAfterAdd עם שדות ששונו; עבור אירועים אחרי-פעולה, אין צורך בהחזרה, אך ניתן לתעד.
3. רשמו את המטפל דרך EventResult עם שם המחלקה המלא המדויק.
4. ודאו שהפעולה נקראת דרך ORM (EventManager::addEventHandler), לא דרך ה-API הישן.

המטפל מקבל אובייקט DataManager::add(). הפרמטרים נשלפים:

public static function onAfterAdd(\Bitrix\Main\Entity\Event $event): void { $result = $event->getParameter('result'); // объект Result с ID $fields = $event->getParameter('fields'); // массив сохранённых полей $newId = $result->getId(); $userId = $fields['USER_ID'] ?? null; } 

עבור אירועים לפני-פעולה, שנו שדות דרך \Bitrix\Main\Entity\Event:

public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event): \Bitrix\Main\Entity\EventResult { $result = new \Bitrix\Main\Entity\EventResult(); $result->modifyFields(['CREATED_BY' => \CUser::GetID()]); return $result; } 

טעויות נפוצות: שם מחלקה שגוי, שימוש ב-API ישן שעוקף אירועי ORM, או שכחה להחזיר public static function onAfterAdd(\Bitrix\Main\Entity\Event $event): void { $result = $event->getParameter('result'); // объект Result с ID $fields = $event->getParameter('fields'); // массив сохранённых полей $newId = $result->getId(); $userId = $fields['USER_ID'] ?? null; } באירועים לפני-פעולה. תמיד בדקו עם 10,000 רשומות כדי להבטיח ביצועים.

תרחישים מעשיים למטפלי ORM

• ביקורת שינויים: תיעוד מי ומתי שינה רשומה בטבלת HL מותאמת אישית. כתיבה לטבלת ביקורת עם מזהה ישות, משתמש ושינויים מסודרים.
• מילוי אוטומטי של שדות: הגדרה אוטומטית של תאריך יצירה, סטטוס, hash בעת הוספה.
• מחיקה מדורגת: לפני מחיקת הרשומה הראשית, ניקוי נתונים קשורים (לדוגמה, בעת מחיקת הזמנה, מחיקת פריטיה). ORM אינו עושה זאת אוטומטית; המטפל שומר על שלמות הנתונים.

כיצד ליישם מחיקה מדורגת עם אירועי ORM?

למחיקה מדורגת, רשמו מטפל EventResult על מחלקת DataManager האב. במטפל, אספו את כל הרשומות הקשורות ומחקו אותן באמצעות DataManager::delete() שלהן. זה מבטיח שלמות התייחסותית ומפעיל אירועי ילדים כראוי. דוגמה: מחיקת הזמנה מסירה גם את פריטי ההזמנה ועסקאות תשלום.

השוואה: אירועי ORM לעומת אירועים ישנים

הערה: אירועי ORM מופעלים רק בעת שימוש ב-$arParams, EventResult::modifyFields(), EventResult::addError(). קריאות SQL ישירות או API ישן עוקפות אותם.

יתרונות ביצועים לפרויקטים בעומס גבוה

באתרים עם מיליוני רשומות, כל טריגר נוסף מגדיל את זמן התגובה. אירועי ORM מגיבים רק לשינויים הנדרשים, ומפחיתים את העומס. אנו משתמשים במטמון מתויג, שאילתות ממוזערות ואינדקסים. בפרויקט אחד, מעבר לאירועי ORM קיצר את זמן שמירת המוצר ב-40% (מ-2.5 שניות ל-1.5 שניות לפריט), והפחית את עלויות השרת ב-1,500 דולר חודשיים. ההשקעה מחזירה את עצמה תוך חודשיים.

בלוקים Highload ואירועי ORM

עבור בלוקים HL, מחלקת DataManager נוצרת דינמית. מצאו את המחלקה:

public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event): \Bitrix\Main\Entity\EventResult { $result = new \Bitrix\Main\Entity\EventResult(); $result->modifyFields([ 'CREATED_AT' => new \Bitrix\Main\Type\DateTime(), 'STATUS' => 'DRAFT', 'HASH' => md5(uniqid('', true)), ]); return $result; } 

לאחר מכן רשמו מטפל על אירועי אותה מחלקה. עבור מספר בלוקי HL, צרו נתב אוניברסלי.

תוצרים

• ניתוח מודל האירועים הנוכחי וסכימת הנתונים
• עיצוב מבנה המטפל עם לוגיקה עסקית
• יישום על ORM D7 עם בדיקות עומס (10,000 אירועים לדקה)
• תיעוד: סכימה, פרמטרים, דוגמאות (בהתבסס על קורס ORM D7 הרשמי של 1C-Bitrix)
• אחריות למשך 6 חודשים על הקוד ותמיכה לאחר מסירה
• הדרכה לצוות שלכם

לוחות זמנים

דוגמאות: ראו תיעוד רשמי: קורס ORM D7

הזמנת פיתוח במפתח סגור

השלמנו למעלה מ-50 פרויקטים על 1C-Bitrix, תוך שימוש ב-ORM D7, מטמון מתויג ומודל אירועים. צרו קשר לייעוץ והערכה מדויקת לפרויקט שלכם. כתבו לנו.