تنفيذ الكيانات

الدرس 33 من 38 · التنفيذ · 8 دقيقة و16 ثانية

الفيديو الأصلي باللغة الإنجليزية. إذا تعذّر تشغيله هنا، شاهده على موقع المؤلف. التفريغ النصي العربي الكامل أدناه.

الموارد

• مستودع المشروع..... تحقق من ال restaurant-entities فرع.

التفريغ النصي

[00:03] دعونا نتحدث عن كيف يمكننا تمثيل كيانات نطاقنا في قاعدة الشيفرة. لذلك كما ناقشنا سابقًا، فإن الكيانات هي اللبنات الأساسية لمجالك. في حالة نطاق FullSnack، تشمل بعض كياناتنا المطاعم والعملاء وبطاقات التسوق وعناصر القائمة وما إلى ذلك. وبما أن هذه هي جوهر المجال بأكمله، فإنها تظهر في النظام بأكمله، ليس فقط في واجهة المستخدم الخاصة بك، ولكن أيضا في قواعد البيانات الخاصة بك، جداول قاعدة البيانات، على سبيل المثال. وفي نقاط نهاية API الخاصة بك.

[00:36] هنا لدينا مثال على واجهة برمجة التطبيقات الأساسية الخاصة بنا. هذه نقطة نهاية من واجهة برمجة التطبيقات الأساسية الخاصة بنا، والتي اعتدنا استخدامها للحصول على معلومات حول مطعم معين. إذاً هذه نقطة نهاية مطعم، تأخذ معرّف وتعطينا معلومات عن ذلك المطعم. هذا نموذجي جداً. إنه يحصل لنا على مجموعة من البيانات حول الهوية، وحول المطعم، ويمكننا استخدام نقاط النهاية هذه يمكننا استدعاء نقاط النهاية هذه من تطبيقك، باستخدام شيء مثل هذا بسيط للغاية لدي وظيفة جلب بسيطة للغاية والتي ببساطة تستدعي نقطة النهاية التي تمرر الهوية ثم تعيد بعض JSON.

[01:13] لدي أيضًا بعض دوال الجلب الإضافية هنا للحصول على قائمة المطعم وفئات المطاعم. الآن، من الشائع جدًا ومن المعتاد جدًا استخدام دوال الجلب هذه مباشرة في تطبيقك، في مكوناتك. لذلك سأقول أنه بالنسبة لحالات الاستخدام البسيطة، لا بأس بذلك تمامًا. عندما تقوم نقطة النهاية بإرجاع كميات صغيرة جدًا من البيانات أو عندما يتم استخدام أو متى في مكان واحد فقط. أعتقد أن مجرد استدعاء طريقة الجلب مباشرة، ربما يكون على ما يرام.

[01:45] ولكن عندما يتعلق الأمر بالكيانات الخاصة بك، أود أن تعريف طبقة من التجريد على أعلى من ذلك. سأريك كيف يبدو هذا في دقيقة واحدة. الآن، دعونا نرى، ما هي المشكلة في مجرد استخدام دالة الجلب هذه مباشرة في مكوناتنا؟

[01:58] لذلك لنفترض أنني أريد استخدام هذه الوظيفة في شاشة مطعمي هنا. هذه هي نقطة الدخول الرئيسية لشاشة المطعم. كما قد تتذكر، يبدو شيئًا من هذا القبيل ويعرض جميع المعلومات حول مطعم معين. اذاً يمكنني ان اسمي هذه الدالة هنا أستطيع أن أقول مطعم ينتظر جلب مطعم، ويمكنني أن أدعو هذا وظيفة مطعم جلب. وأنا ذاهب فقط للذهاب hardcode معرف واحد من هنا. ولكن بالطبع، قد يكون هذا شيئًا يأتي من عنوان URL. ودعونا فقط طباعة تلك البيانات هنا على الجسم من وظيفة التطبيق.

[02:42] هذه هي الطريقة التي تبدو بها البيانات تمامًا كما تأتي من واجهة برمجة التطبيقات. هناك بعض المشاكل مع هذا. واحد هو أن السمات متداخلة هنا داخل هذه الصفات سمات المجلد الكائن. هناك أيضًا كائنات هذه العلاقة هنا وهذه اتفاقيات من مواصفات API الخاصة بي، لكنها ليست مفيدة بشكل خاص لواجهتي الأمامية. أنا لا أهتم بالفرق بين الصفات والعلاقات. أريد فقط جلب بعض البيانات.

[03:04] كما أنه يأتي مع بعض البيانات التي قد لا نحتاج إليها. ربما لا أحتاج إلى هذه الصفحة بالذات. هناك معلومات حول ما تقدمه، إذا كانت تقدم التسليم والتقاط وهلم جرا. كما أن بعض البيانات غير كاملة. قائمة هذه الفئات، على سبيل المثال، تتضمن اسم الفئة، وهو الشيء الوحيد الذي أهتم به. أنا لا أهتم بالهويات. أنا فقط أهتم بالاسم وبالتالي فإن البيانات ليست في الشكل الذي هو مفيد بالنسبة لي كمطور الواجهة الأمامية عندما أريد تقديم شيء على الشاشة هنا في الاستعراضات، ولدي أيضا بعض البيانات التي لا أحتاج إليها، وهذا هو أيضا متداخلة بعمق بطريقة أنني لا تحتاج إلى أن يكون في هذا الشكل.

[03:41] لذلك هناك بعض أوجه القصور في بنية البيانات هذه التي يمكننا حلها من خلال تنفيذ ما أحب أن أسميه نموذج. دعوني أريكم كيف يبدو النموذج. هذه هي طبقة التجريد التي سنضيفها إلى واجهة برمجة التطبيقات الخاصة بنا. أو بين واجهة برمجة التطبيقات الخاصة بنا والواجهة الأمامية لجعلها أسهل وأبسط للتعامل مع البيانات عبر تطبيقنا.

[04:05] حسنا. لذلك اسمحوا لي أن أبدأ بتدوير كل هذا مرة أخرى. لذلك سأعود إلى الحالة الأصلية والمكان الذي أحب أن أبدأ فيه عند تعريف النموذج هو تحديد النوع أولاً. إذا كنت أستخدم typescript، فأنا أحب الاستفادة من ذلك وتحديد نوع الكيان الخاص بي. هذه الحالة، لدينا نوع المطعم، وهو بنية بيانات مبسطة لما أريد أن يتم تمثيل كيان المطعم في الواجهة الأمامية. في الوحدة السابقة، قد تتذكر أننا قمنا بممارسة نمذجة المجال هذه لتحديد شكل كياناتنا بحيث يمكن أن يأتي هذا التمرين. يمكننا أن نكون مفيدين جدا في هذه الحالة.

[04:45] لدينا أيضًا بياناتنا المبسطة، كائن مراجعة عملائنا هنا لسمات مراجعاتنا، وهذا هو أساسًا جميع البيانات التي نحتاجها لهذه الصفحة بالذات، على سبيل المثال. الآن كيف يمكننا تعريف نموذج؟ ثم يمكن أن يأخذ نموذجنا شكل صفنا عادة، لكنني أحب تعريفه كدالة بدلاً من ذلك. والنموذج له أغراض. يجب عليه إرجاع كائن يتوافق مع نوع البيانات الخاص بنا. في هذه الحالة، نريد إرجاع كائن له الشكل، وسيقوم بتجميع البيانات من جميع مصادر البيانات المختلفة اللازمة لإنشاء هذا الكائن.

[05:23] لذلك يمكننا أن نبدأ بتحديد وظيفة تسمى getRestaurant، في هذه الحالة التي تعود، في هذه الحالات هو Promise، لأنه على وظيفة غير متزامنة ويعيد Promiseنا من كائن مطعمنا كما هو النوع الذي عرفناه سابقًا. وسأبدأ بالقيام بنفس الشيء الذي كنت أفعله من قبل. سأدعو جلب البيانات أو جلب وظيفة المطعم وسوف انتزاع الصفات والعلاقات العلاقات هنا. سأدعو هذه النقاط النهائية الأخرى تسمى فئات المطاعم، وهذا لأنني أريد الحصول على أسماء الفئات أيضًا. هذا هو المكان الذي يحدث فيه تجميع نقاط النهاية المتعددة.

[06:02] وأخيرا، سوف أرسم خريطة من خلال قائمة المراجعات. هذا هو تبسيط بنية البيانات بحيث لا يكون لدي هذه الكائنات المتداخلة بعمق وليس لدي أي بيانات غير ضرورية. وأخيرًا، سأعيد كائنًا في شكل يتوافق مع نوع البيانات الخاص بي. كما كنت قد لاحظت. الآن، ليس لدي خطأ هنا في وظيفتي، مما يعني أن هذا الكائن في الشكل الذي كنت أتوقع أن أكون في الواجهة الأمامية.

[06:28] والآن يمكننا استخدام هذه الدالة للحصول على وظيفة المطعم، وهو نموذجنا في أي مكونات أو أي وظائف قد تحتاج إلى تلك البيانات حول المطعم. لذلك في أي وقت نحتاج إلى الاستيلاء على كيان المطعم، يمكننا استدعاء هذه الوظيفة. هنا، لدينا مثال في هذا المطعم. عنصر رأس، وهو واحد، الذي نراه هنا في الجزء العلوي حيث يمكنني الاتصال، اسمحوا لي أن إلغاء هذا ويقول أستطيع أن أقول انتظر الحصول علىالمطعم وأحصل على شيفرة الثابت، معرف في الوقت الراهن. ولكن هذا بالطبع سيأتي من عنوان URL.

[07:07] لذلك أنا ذاهب لانقاذ ذلك وسوف نرى. نحن نعبر الجسم بأكمله. قد لا نرغب في تمرير الشيء بأكمله، لكننا هنا نمرر الكائن بالكامل إلى معلومات المطعم، والتي تأخذ كائنًا من نوع كيان المطعم. وسوف يقوم وسوف يقوم بطباعة تلك البيانات هنا. هذه هي الطريقة التي يعمل بها. بالطبع، في التطبيق الحقيقي، نود أن نصممه بشكل أكثر لطفًا، ولكن هذه هي الطريقة الأساسية التي يمكننا من خلالها تمرير البيانات من واجهة برمجة التطبيقات على طول الطريق إلى المكونات التي تحتاجها بطريقة تحترم شكل الكيان كيف نريد أن تبدو في المقدمة.

[07:42] لذلك هذا هو عرض أكثر تبسيطا بكثير من كياننا مقارنة مع ما نحصل عليه من الخلفية. قد يبدو هذا تحسنا صغيرا، ولكن تذكر أن هذه الكيانات هي جوهر التطبيق بأكمله. لذا فإن أي أوجه قصور قد تكون لديك، أو أي سمات متداخلة أو بيانات غير مكتملة أو بيانات غير ضرورية قد تكون لديك في كائنك يمكن أن تنتشر حقًا إلى ذلك من خلال النسخ الكاملة المستثمرة في إنشاء نموذج، حتى لو كان شيئًا بسيطًا مثل هذه الوظيفة التي أنشأناها هنا عادة ما يكون استثمارًا جيدًا للغاية.