framework.php
1.0.0
هذا إطار لتطوير الفريق الصغيرة والمتوسطة الحجم
مدونة شخصية بسيطة bybzmt/blog.php
المدونة الشخصية bybzmt/blog.php استنادًا إلى هذا الإطار لها أداء قوي للغاية
| نموذج | ملفات ثابتة | الصفحة الرئيسية (مدونة) | الصفحة الرئيسية (10 مدونات) |
|---|---|---|---|
| FPM | 4705 | 1507 | 1237 |
| سوول | 26607 | 3276 | 2084 |
├── assets 资源目录(如:字体文件等)
├── config
│ ├── dev 开发环境配置
│ ├── product 生产环境配置
├── index.php 项目入口
├── library 其它与composer不兼容的库
├── src
│ ├── Admin 管理后台
│ ├── Api app接口端
│ ├── Backend 内部(内网)接口
│ ├── Common 公共代码目录
│ ├── Console 控制台
│ ├── Wap 手机Web端
│ └── Web Web端
├── static
│ ├── admin 后台静态文件
│ └── web Web端静态文件
├── tests 单元测试目录
├── var 可读写目录(如:模板缓存等)
└── vendor composer库
نظرًا لأن Swoole هو وضع ذاكرة مقيم ، فإن دورة حياة المتغيرات العالمية هي مستوى التطبيق ، وعلى عكس وضع FPM ، فهي على مستوى الطلب فقط. يمكن الحفاظ على المتغيرات العالمية بين الطلبات المختلفة ، وبالتالي لا يمكن استخدام الأساليب الأصلية مثل $ _get و $ _post. يقوم هذا الإطار بتركيب كائن سياق لكل طلب ويخزن جميع البيانات المتعلقة بالطلب الحالي في كائن السياق.
كائن السياق مسؤول أيضًا عن تحميل المكون واستبدال الوظائف في التسلسل الهرمي.
كما في المدونة أعلاه:
عند تهيئة المكون ، سيبحث كائن السياق أولاً عن المكون المقابل في مساحة الاسم. إذا لم يتم العثور عليها ، فسيتم تهيئة سياق الأصل. وبهذه الطريقة ، يمكنه بسهولة توسيع المكونات التي تحتاجها واستبدالها.
API:
كائن الطلب هو swoole_http_request يتم استخدامه مباشرة
تستخدم كائنات الاستجابة أيضًا swoole_http_response مباشرة
في وضع FPM ، يقوم الإطار بتنفيذ طبقة توافق للحفاظ على واجهة برمجة التطبيقات نفسها كما في Swoole
يقوم الإطار بتطبيق جميع الكائنات المتعلقة بكائنات السياق كمكون ، وذلك أساسًا لتوفير وظائف تسوية سريعة ، ولا تتطلب انتقالًا متكررًا لكائنات السياق.
بالإضافة إلى ذلك ، يحتوي المكون أيضًا على بعض الطرق المريحة لاستخدامها في أي مكون.
لا تعتمد الدرابزين على رسم الخرائط المفتوحة ، ولكنه يستخدم التوجيه المسجل ، مع ميزة كونها نظيفة نسبيًا.
يقع مشروع التوجيه في bybzmt/router.php
إذا كنت لا تحب ذلك ، فيمكنك استبدالها بالمكتبة التي تحبها ، ومن السهل جدًا استبدال مكونات الإطار.
يوصي الإطار باستخدام نمط نموذج المجال ، باستخدام: الخدمة ، الجدول ، الصف (المجال)
تجدر الإشارة إلى أنه لا ينبغي كتابة عمل عرض البيانات في الخدمة والجدول والصف. إنه مسؤول فقط عن توفير البيانات الأساسية. يجب تنظيم بنية البيانات المقابلة وفقًا للصفحة ومتطلبات واجهة برمجة التطبيقات في وحدات التحكم والآراء.
تنقسم قاعدة البيانات إلى فئة الجدول التي توفر وظائف أساسية وفئة Tablesplit التي توفر وظائف الجدول. هناك أيضًا سمة TableRowCache التي توفر وظيفة التخزين المؤقت. يجب أن يتم توريث جدول أي مستخدم من فئة الجدول أو TableSplit ، وعندما تكون ذاكرة التخزين المؤقت مطلوبة ، يمكن تقديمها.
لاحظ أن كل من الجدول وذاكرة التخزين المؤقت يدعمان فقط عمليات GET/GET/INSERT/UPDATE/DELETE في فئة الجدول. عند استخدام SQL لإجراء عمليات البيانات مباشرة ، تحتاج إلى الحفاظ على وظائف ذاكرة التخزين المؤقت أو الجدول ذات الصلة يدويًا.
يوفر الإطار طريقة تحميل Lazyrow. عند إنشاء مثيل له ، يسجل المعرف فقط ثم يحاول التحميل على دفعات حتى يتم الوصول إلى السمة.
يوفر الإطار بعض الوظائف الشائعة وهو مناسب للاستخدام
لا علاقة لذاكرة التخزين المؤقت هذه مع ذاكرة التخزين المؤقت في الجدول أعلاه ، فهي تشير إلى ذاكرة التخزين المؤقت التي يحتفظ بها المستخدم. حاول السماح بأنواع مختلفة من ذاكرة التخزين المؤقت مع فصول مختلفة لتجنب النزاعات الرئيسية.
لا يوفر الإطار وظائف قالب ، ويوصى به مباشرة إنشاء برامج قالب الطرف الثالث. (على سبيل المثال: غصين)
لا ترغب وظائف الإطار في التكيف مع جميع البيئات ، بل يجب أن تكون متوفرة فقط في 80 ٪ من الحالات. يمكن التعامل مع الظروف الخاصة خصيصا في مشاريع محددة.
لا يوجد الكثير من التعليمات البرمجية في الإطار ، لذا حاول قراءة جميع الكود قدر الإمكان.
