אנו משלבים את D7 API בפרויקטים של Bitrix, יוצרים מחלקות עם מרחבי שמות במקום פונקציות גלובליות, אובייקטי Result במקום bool ומחרוזות שגיאה, ומשתמשים ב-Application כנקודת כניסה במקום משתנים גלובליים. קוד כזה לא נשבר בעדכונים, קל לבדיקה ולשימוש חוזר. הניסיון שלנו: מעל 5 שנים עבודה עם Bitrix, מעל 30 פרויקטים שהועברו במלואם ל-D7. קבלו הערכה לפרויקט שלכם — צרו קשר!
בעיות שאנו פותרים
כאבים אופייניים: קוד legacy המשתמש ב-CModule ו-$_POST נשבר בעדכונים, לא ניתן לכסות אותו בבדיקות, שגיאות אובדות (return false ללא הקשר), וקאש נפסל רק לפי זמן. D7 API פותר זאת באמצעות טיפוסים קפדניים, חריגות וקאש מתויג. כתוצאה מכך, שגיאות ייצור יורדות פי 2–3, וזמן פריסת תכונות חדשות מצטמצם ב-40%.
למה לעבור ל-D7 API?
מעבר ל-D7 API אינו טרנד אלא הכרח עבור פרויקטים שחיים יותר משנה. במקום CIBlockElement::GetList() עם המון פרמטרים, מקבלים שאילתות ORM עם שרשורי מתודות. במקום $_POST['field'] — אובייקט Request עם גישה טיפוסית. הקוד שלכם הופך לצפוי ומתועד. בואו נשווה נפח קוד legacy ו-D7: עבור 1000 שורות legacy, D7 דורש כ-800 שורות, אבל קוד D7 קל יותר לתחזוקה ב-60%.
איך אנו מפתחים מחלקות D7
ניקח מקרה אמיתי: חנות מסחר אלקטרוני על Bitrix עם 50,000 מוצרים. קוד הסל הישן עבד דרך CSaleBasket::Add והיה מפוזר בין תבניות. כתבנו אותו מחדש למחלקת שירות BasketService עם D7:
namespace MyProject\Services; use Bitrix\Main\Result; use Bitrix\Main\Error; use Bitrix\Sale\Basket; class BasketService { public function __construct( private readonly int $userId ) {} public function addItem(int $productId, int $quantity): Result { $result = new Result(); $basket = Basket::loadItemsForUser($this->userId); if (!$basket) { $result->addError(new Error('Не удалось загрузить корзину', 'BASKET_LOAD_FAIL')); return $result; } $item = $basket->createItem('catalog', $productId); $item->setFields(['QUANTITY' => $quantity]); $saveResult = $basket->save(); if (!$saveResult->isSuccess()) { $result->addErrors($saveResult->getErrors()); } return $result; } } עכשיו הסל מכוסה במלואו בבדיקות יחידה, ובעדכוני Bitrix צריך להחליף רק מחלקה אחת, לא לשכתב את כל התבניות. זה צמצם את זמן העדכון מ-3 ימים לשעתיים.
איך D7 API משפר את הקאש
קאש מתויג הוא אחת הנקודות החזקות של D7. במקום פסילת קאש גלובלית לפי זמן, מבטלים רק את הנתונים שהשתנו. לדוגמה, כשמתעדכן מחיר מוצר, רק הקאש של אותו מוצר נפסל, לא כל הקטלוג. זה מפחית את עומס מסד הנתונים ב-30–50%.
דפוסים ארכיטקטוניים: Factory ו-Repository
ללוגיקה מורכבת, אנו משתמשים ב-Factory ליצירת אובייקטים וב-Repository לעבודה עם אחסון. לדוגמה, Factory של הזמנות יוצר מופעי namespace MyProject\Services; use Bitrix\Main\Result; use Bitrix\Main\Error; use Bitrix\Sale\Basket; class BasketService { public function __construct( private readonly int $userId ) {} public function addItem(int $productId, int $quantity): Result { $result = new Result(); $basket = Basket::loadItemsForUser($this->userId); if (!$basket) { $result->addError(new Error('Не удалось загрузить корзину', 'BASKET_LOAD_FAIL')); return $result; } $item = $basket->createItem('catalog', $productId); $item->setFields(['QUANTITY' => $quantity]); $saveResult = $basket->save(); if (!$saveResult->isSuccess()) { $result->addErrors($saveResult->getErrors()); } return $result; } } עם תלויות מוגדרות מראש, ו-Repository של מוצרים עוטף שאילתות ORM עם קאש מתויג. גישה זו מבודדת את הלוגיקה העסקית מהתשתית ומאפשרת החלפה קלה של מימושים בבדיקות.
התהליך שלנו
- ביקורת קוד נוכחי — זיהוי מקומות המשתמשים ב-API legacy.
- עיצוב ארכיטקטורה — הגדרת שירותים, repositories, factories.
- מימוש מחלקות — כתיבת קוד עם Result, Application, קאש מתויג.
- כתיבת בדיקות יחידה — כיסוי תרחישים קריטיים.
- אינטגרציה ופריסה — החלפת מודולים ישנים חלק אחר חלק, תוך שמירה על תאימות לאחור.
מידע נוסף על עקרונות פיתוח
כל מחלקת שירות צריכה להיות ממוקדת ואחראית לפעולה עסקית אחת. אנו משתמשים בהזרקת תלויות דרך הבנאי, לא דרך פונקציות גלובליות. זה הופך את הקוד לבדיק ולהחלפה.מה כלול
- סט מלא של מחלקות D7 (שירותים, repositories, factories, אובייקטי Result)
- תיעוד API ב-PHPDoc
- בדיקות יחידה (לפי בקשה)
- התאמת קוד קיים לעבודה עם מחלקות חדשות
- הוראות התקנה ותחזוקה
D7 API לעומת Legacy API
| קריטריון | Legacy API | D7 API |
|---|---|---|
| טיפול בשגיאות | Order |
return false עם מערך שגיאות |
| טיפוסים | Mixed | קפדני (PHP 8.1+) |
| יכולת בדיקה | נמוכה (פונקציות גלובליות) | גבוהה (DI) |
| קאש | TTL | פסילה מתויגת |
| עדכון Bitrix | לעתים קרובות נשבר | תואם לגרסאות חדשות |
לוחות זמנים
| משימה | לוח זמנים |
|---|---|
| סט מחלקות שירות לתכונה אחת (5–10 מחלקות) | 1–2 שבועות |
| שכבת שירות מלאה למודול (repositories, services, factories, אובייקטי Result) | 3–5 שבועות |
| כתיבת בדיקות יחידה למחלקות מוכנות | +30–50% מזמן הפיתוח |
קוד על D7 API חי לאורך זמן. ניתן לעדכן אותו חלק אחר חלק, לבדוק ולעשות בו שימוש חוזר. הזמינו פיתוח מחלקות D7 במפתחות מלאות — נבצע הערכה לפרויקט שלכם ביום אחד. תאימות מובטחת לגרסאות Bitrix העדכניות.
למדו עוד על D7 API בתיעוד הרשמי ובויקיפדיה על מרחבי שמות ב-PHP.
צרו קשר לייעוץ — נעזור לכם במעבר ל-D7. קבלו הצעה מסחרית והערכת עלות תוך יום.







