تطبيق وصل wassll لمتابعة مخصصات المحروقات

شرح بنية مشروع Laravel وملفات ومجلدات التطبيق

بعد أن قمنا في الدرس السابق بتجهيز بيئة العمل وإنشاء أول مشروع Laravel وتشغيله على جهاز الكمبيوتر، حان الوقت الآن للتعرف على المشروع من الداخل.

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

قد ترى مجلدات مثل:

app
bootstrap
config
database
public
resources
routes
storage
tests
vendor

بالإضافة إلى ملفات مثل:

.env
artisan
composer.json
package.json

وقد تسأل نفسك:

• أين أكتب الكود؟
• أين أضع الصفحات؟
• أين توجد قاعدة البيانات؟
• أين أكتب المسارات؟
• أين أضع Controllers؟
• ما وظيفة مجلد public؟
• ولماذا يوجد مجلد vendor؟
• وما الفرق بين resources وpublic؟

في هذا الدرس سنجيب عن هذه الأسئلة بالتفصيل.

فهم بنية المشروع ليس أمرًا ثانويًا، بل هو من أهم الخطوات التي يجب أن يتقنها مطور Laravel؛ لأنك كلما تقدمت في الكورس ستتعامل باستمرار مع هذه المجلدات.

والأهم من ذلك أن Laravel يعتمد على بنية واضحة ومنظمة، وهذا التنظيم يسمح لك بالعثور على الملفات التي تحتاج إليها بسرعة، كما يجعل المشروع أسهل في التطوير والصيانة والعمل الجماعي. وتوضح وثائق Laravel الرسمية أن البنية الافتراضية للمشروع صُممت لتكون نقطة بداية مناسبة للمشاريع الصغيرة والكبيرة، مع إمكانية تنظيم المشروع حسب الحاجة طالما أن Composer قادر على تحميل الأصناف البرمجية بشكل صحيح.

نظرة عامة على بنية مشروع Laravel

عند إنشاء مشروع Laravel حديث، ستجد بنية قريبة من الشكل التالي:

my-app/
│
├── app/
├── bootstrap/
├── config/
├── database/
├── public/
├── resources/
├── routes/
├── storage/
├── tests/
├── vendor/
│
├── .env
├── artisan
├── composer.json
├── package.json
└── ...

لا تحتاج إلى حفظ هذه البنية الآن.

هدفنا في هذا الدرس هو أن تفهم وظيفة كل جزء.

مع مرور الوقت، ستصبح هذه المجلدات مألوفة جدًا بالنسبة لك، وستعرف مباشرة أين يجب أن تضع كل نوع من الأكواد.

مجلد app

يعتبر مجلد:

app/

من أهم المجلدات في مشروع Laravel.

فهو يحتوي على الجزء الأساسي من كود التطبيق الذي ستقوم بكتابته وتطويره.

وفقًا للتوثيق الرسمي، معظم الأصناف Classes الخاصة بالتطبيق تكون داخل مجلد app، ويستخدم Laravel وComposer نظام PSR-4 لتحميل هذه الأصناف تلقائيًا.

يمكن أن تجد بداخله مجلدات مثل:

app/
├── Http/
├── Models/
└── Providers/

ومع تطور المشروع واستخدام أوامر Artisan لإنشاء مكونات جديدة، يمكن أن تظهر مجلدات أخرى مثل:

Events/
Jobs/
Listeners/
Mail/
Notifications/
Policies/
Rules/

ليس من الضروري أن تكون جميع هذه المجلدات موجودة منذ اللحظة الأولى؛ بعض المجلدات يتم إنشاؤها عند الحاجة إليها.

مجلد app/Http

من أهم المجلدات داخل app:

app/Http/

وهو المكان الذي توجد فيه المكونات المرتبطة بالتعامل مع طلبات HTTP.

يمكن أن يحتوي على:

app/Http/
├── Controllers/
├── Middleware/
└── Requests/

سنستخدم هذه المجلدات كثيرًا خلال الكورس.

مجلد Controllers

app/Http/Controllers/

يحتوي على Controllers.

والـ Controller هو المكان الذي نضع فيه جزءًا من منطق التعامل مع الطلبات.

على سبيل المثال، يمكن أن يكون لدينا:

ArticleController.php

مسؤولًا عن التعامل مع عمليات المقالات.

وفي الدروس القادمة سنتعلم كيف ننشئ Controller باستخدام Artisan، وكيف نربطه بالـ Routes.

مجلد Middleware

يمكن أن تجد Middleware داخل:

app/Http/Middleware/

وهو يستخدم لتنفيذ عمليات معينة قبل أو بعد وصول الطلب إلى الجزء المطلوب من التطبيق.

على سبيل المثال، يمكن استخدام Middleware للتحقق من أن المستخدم قام بتسجيل الدخول قبل السماح له بالدخول إلى لوحة التحكم.

سنشرح Middleware بالتفصيل في درس مستقل.

مجلد Form Requests

يمكن أن يحتوي:

app/Http/Requests/

على Form Request Classes.

وتستخدم هذه الأصناف في تنظيم والتحقق من البيانات التي يرسلها المستخدم.

على سبيل المثال، إذا كان لدينا نموذج لإنشاء مقال، يمكننا إنشاء Request خاص بقواعد التحقق من عنوان المقال ومحتواه.

وهذا يجعل الكود أكثر تنظيمًا عندما تصبح المشاريع كبيرة.

مجلد app/Models

المجلد:

app/Models/

مخصص لنماذج Eloquent.

وإذا كنت تتذكر ما تحدثنا عنه في الدرس الأول، فإن Eloquent هو نظام ORM الموجود داخل Laravel للتعامل مع قاعدة البيانات.

فمثلًا إذا كان لدينا جدول:

articles

يمكن أن يكون لدينا Model يسمى:

Article.php

ويكون موجودًا في:

app/Models/Article.php

ومن خلال هذا النموذج يمكننا التعامل مع البيانات الموجودة في جدول المقالات.

يمكن استخدام Model في عمليات مثل:

• قراءة البيانات.
• إضافة البيانات.
• تعديل البيانات.
• حذف البيانات.
• تعريف العلاقات بين الجداول.

وتوضح وثائق Laravel أن مجلد Models يحتوي على أصناف Eloquent التي تستخدم للتعامل مع جداول قاعدة البيانات.

مجلد app/Providers

المجلد:

app/Providers/

يحتوي على Service Providers الخاصة بالتطبيق.

في المشروع الجديد ستجد عادة:

AppServiceProvider.php

Service Providers لها دور مهم في تهيئة التطبيق وتسجيل الخدمات داخل Service Container وتنفيذ عمليات الإعداد التي يحتاج إليها التطبيق.

في بداية تعلم Laravel لن تحتاج إلى تعديل هذا المجلد كثيرًا، لذلك لا تقلق إذا لم تفهمه بشكل كامل الآن.

سنعود إليه عندما نتحدث عن Service Container وService Providers.

مجلد bootstrap

المجلد:

bootstrap/

مسؤول عن عملية تهيئة إطار Laravel.

من الملفات المهمة بداخله:

bootstrap/app.php

وهو ملف يستخدم لتهيئة التطبيق.

كما يحتوي المجلد على ملفات Cache ينشئها Laravel لتحسين الأداء، مثل الملفات المتعلقة بتخزين بعض المعلومات التي تم توليدها بواسطة الإطار.

بصفتك مبتدئًا، لا تحتاج إلى تعديل هذا المجلد بشكل متكرر.

الأفضل أن تعرف وظيفته وأن تترك الملفات الموجودة فيه تعمل كما صممت.

مجلد config

المجلد:

config/

يحتوي على ملفات إعدادات التطبيق.

يمكن أن تجد بداخله ملفات مرتبطة بإعدادات مختلفة، مثل:

app.php
database.php
cache.php
filesystems.php
logging.php
mail.php
queue.php
services.php

وقد تختلف الملفات الموجودة حسب إصدار Laravel والمكونات التي تستخدمها.

فكرة هذا المجلد بسيطة:

بدلًا من وضع جميع إعدادات التطبيق داخل ملفات الكود، يتم فصل الإعدادات في ملفات مستقلة.

على سبيل المثال، إعدادات قاعدة البيانات تكون مرتبطة بملف:

config/database.php

بينما إعدادات البريد تكون مرتبطة بإعدادات البريد الخاصة بالتطبيق.

وتوضح وثائق Laravel الرسمية أن جميع ملفات إعدادات إطار العمل الخاصة بالتطبيق موجودة داخل مجلد config.

ما الفرق بين config و .env؟

هذه نقطة مهمة جدًا.

قد ترى أن بعض إعدادات Laravel موجودة في:

config/

وفي الوقت نفسه هناك ملف:

.env

فما الفرق؟

ملفات config تحتوي على تعريفات وإعدادات التطبيق.

أما .env فيستخدم لتحديد قيم تختلف حسب بيئة التشغيل.

مثلًا، قد يكون لديك مشروع واحد يعمل:

• على جهاز المطور.
• على خادم الاختبار.
• على خادم الإنتاج.

وقد تحتاج كل بيئة إلى إعدادات مختلفة.

يمكن أن يكون اسم قاعدة البيانات مختلفًا، أو بيانات الاتصال بها مختلفة، أو إعدادات البريد مختلفة.

لهذا تستخدم Laravel ملف .env.

مثال:

APP_NAME=Laravel
APP_ENV=local
APP_DEBUG=true

وفي إعدادات قاعدة البيانات يمكن أن توجد قيم مثل:

DB_CONNECTION=sqlite

أو إعدادات MySQL حسب البيئة.

من المهم جدًا عدم وضع المعلومات السرية مباشرة داخل ملفات المشروع العامة، كما يجب عدم رفع .env إلى مستودع عام؛ لأن هذا الملف قد يحتوي على بيانات اعتماد ومفاتيح حساسة.

مجلد database

المجلد:

database/

مرتبط بكل ما يتعلق بقاعدة البيانات.

يمكن أن تجد بداخله:

database/
├── factories/
├── migrations/
└── seeders/

وقد يحتوي أيضًا على ملف SQLite في المشاريع الجديدة التي تستخدم SQLite افتراضيًا. وتوضح وثائق Laravel الحالية أن تطبيقًا جديدًا يمكن أن يأتي مهيأً لاستخدام SQLite، مع إنشاء ملف قاعدة البيانات وتشغيل عمليات الترحيل اللازمة أثناء إنشاء التطبيق.

مجلد migrations

داخل:

database/migrations/

نضع ملفات Migrations.

الـ Migration هو ملف يصف تغييرًا في بنية قاعدة البيانات.

مثلًا يمكن إنشاء Migration لإنشاء جدول:

articles

يحتوي على:

id
title
content
created_at
updated_at

الميزة هنا أنك لا تحتاج إلى إنشاء الجداول يدويًا في كل جهاز.

يمكن للمطورين مشاركة ملفات Migration مع المشروع، ثم تشغيلها لإنشاء البنية المطلوبة لقاعدة البيانات.

سنخصص درسًا كاملًا للـ Migrations لاحقًا.

مجلد factories

المجلد:

database/factories/

يستخدم لإنشاء بيانات تجريبية.

فمثلًا إذا كنت تطور متجرًا إلكترونيًا وتحتاج إلى إنشاء 1000 منتج تجريبي، بدلًا من إدخال المنتجات يدويًا، يمكنك استخدام Factory لإنشاء بيانات وهمية.

وهذا مفيد جدًا أثناء التطوير والاختبار.

مجلد seeders

المجلد:

database/seeders/

يستخدم لإدخال بيانات أولية إلى قاعدة البيانات.

على سبيل المثال، قد ترغب عند إنشاء التطبيق في إضافة:

• مستخدم مدير.
• تصنيفات أساسية.
• إعدادات افتراضية.

يمكن استخدام Seeders لتنفيذ هذه المهام.

مجلد public

المجلد:

public/

مهم جدًا في Laravel.

يحتوي على:

index.php

وهو نقطة الدخول الأساسية للطلبات التي تدخل إلى التطبيق.

كما يمكن أن يحتوي على ملفات عامة مثل الصور وملفات CSS وJavaScript المبنية والمستخدمة مباشرة من المتصفح.

لكن هناك نقطة أمنية مهمة جدًا:

عند نشر Laravel على خادم حقيقي، يجب أن يكون Web Root موجهًا إلى مجلد public، وليس إلى المجلد الرئيسي للمشروع.

السبب هو حماية ملفات المشروع الداخلية من الوصول المباشر عبر الإنترنت.

لا يجب أن يستطيع الزائر الوصول مثلًا إلى:

.env
composer.json

أو ملفات PHP الداخلية لمجرد معرفة عنوان الموقع.

ولهذا تؤكد وثائق Laravel أنه ينبغي تقديم التطبيق من جذر دليل الويب الصحيح، وعدم تشغيله من مجلد فرعي بطريقة قد تكشف الملفات الحساسة.

مجلد resources

المجلد:

resources/

من المجلدات التي ستتعامل معها كثيرًا.

يحتوي على الموارد غير المبنية أو غير المجمعة للتطبيق، ومن أهمها Views وملفات CSS وJavaScript المصدرية.

في تطبيق Laravel الذي يستخدم Blade، ستجد غالبًا:

resources/views/

وهنا نضع ملفات الواجهات.

على سبيل المثال:

resources/views/home.blade.php

يمكن أن يكون ملف الصفحة الرئيسية.

وسنتعلم في درس Blade كيفية إنشاء هذه الصفحات وربطها بالـ Routes وControllers.

الفرق بين resources و public

هذه نقطة يخطئ فيها كثير من المبتدئين.

لدينا:

resources/

ولدينا:

public/

فما الفرق؟

بشكل مبسط:

resources يحتوي على الملفات المصدرية التي يستخدمها المطور أثناء بناء التطبيق.

أما public فهو الجزء الذي يمكن لخادم الويب تقديم ملفاته مباشرة للمتصفح.

مثلًا يمكن أن تضع ملفات CSS المصدرية داخل:

resources/css/

ثم يتم التعامل معها ضمن عملية بناء الواجهة.

أما الملفات التي يجب أن تكون متاحة مباشرة من الويب فتكون ضمن public.

ستصبح هذه الفكرة أوضح عندما نتعلم Vite في جزء الواجهة الأمامية.

مجلد routes

المجلد:

routes/

من أكثر المجلدات التي سنستخدمها أثناء الكورس.

هذا هو المكان الذي نعرّف فيه Routes الخاصة بالتطبيق.

في Laravel 13، يحتوي المشروع الجديد افتراضيًا على:

routes/
├── web.php
└── console.php

ملف:

routes/web.php

هو المكان الأساسي لمسارات الويب.

أما:

routes/console.php

فيستخدم لتعريف أوامر Console المبنية بطريقة Closure، ويمكن استخدامه أيضًا في جدولة المهام.

ومن المهم الانتباه إلى أن api.php ليس بالضرورة موجودًا في المشروع الجديد افتراضيًا؛ يمكن تثبيت مسارات API باستخدام:

php artisan install:api

وهذا يختلف عن بعض الإصدارات أو الشروحات القديمة التي قد تفترض وجود api.php منذ البداية.

ما هو Route؟

قبل أن نبدأ درس Routing بالتفصيل، نحتاج إلى فهم الفكرة الأساسية.

عندما يدخل المستخدم إلى:

https://example.com/articles

يجب أن يعرف Laravel ماذا يفعل بهذا الطلب.

الـ Route هو الذي يحدد ذلك.

على سبيل المثال، يمكن أن يكون لدينا:

Route::get('/articles', function () {
    return 'Articles';
});

وهذا يعني أن زيارة:

/articles

باستخدام طلب GET ستؤدي إلى تنفيذ الكود المحدد.

سنتوسع في Routes في الدرس القادم.

مجلد storage

المجلد:

storage/

يستخدم لتخزين الملفات التي ينشئها Laravel أو التطبيق أثناء التشغيل.

وفقًا للتوثيق الرسمي، يمكن أن يحتوي على:

• ملفات Logs.
• ملفات Cache.
• جلسات مخزنة على الملفات.
• ملفات Blade المجمعة.
• ملفات أخرى ينشئها Framework.

وينقسم عادة إلى أجزاء مثل:

storage/
├── app/
├── framework/
└── logs/

storage/app

يمكن استخدامه لتخزين الملفات التي ينشئها التطبيق.

ومن الأمثلة على ذلك الملفات التي يرفعها المستخدمون.

storage/framework

يحتوي على ملفات مؤقتة وملفات Cache وملفات أخرى يحتاج إليها Laravel أثناء التشغيل.

storage/logs

يحتوي على ملفات تسجيل الأخطاء والأحداث Logs.

إذا واجهت مشكلة في التطبيق في المستقبل، فقد يكون من المفيد جدًا مراجعة ملفات Logs الموجودة هنا.

storage/app/public

هناك حالة مهمة وهي:

storage/app/public/

يمكن استخدامها لتخزين الملفات التي يجب أن تكون متاحة للعامة، مثل صور المستخدمين.

ولجعل هذه الملفات متاحة عبر public/storage، يوفر Laravel الأمر:

php artisan storage:link

الذي ينشئ رابطًا رمزيًا إلى مجلد التخزين العام.

سنشرح رفع الملفات والتعامل مع Storage في درس مستقل.

مجلد tests

المجلد:

tests/

مخصص للاختبارات الآلية.

يمكن أن يحتوي على اختبارات:

• Unit Tests.
• Feature Tests.

وتأتي مشاريع Laravel الحديثة مع بنية اختبار جاهزة، ويمكن تشغيل الاختبارات باستخدام:

php artisan test

بحسب إعداد المشروع وأدوات الاختبار المستخدمة.

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

مجلد vendor

المجلد:

vendor/

يحتوي على الاعتماديات التي يقوم Composer بتثبيتها للمشروع.

مثلًا Laravel نفسه يعتمد على عدد من الحزم والمكتبات، ويتم تحميلها داخل هذا المجلد.

لذلك قد يكون حجم vendor كبيرًا نسبيًا.

ولا يجب أن تقوم بتعديل الملفات الموجودة بداخله يدويًا.

إذا احتجت إلى تحديث أو إضافة مكتبة، استخدم Composer.

وتوضح وثائق Laravel أن vendor يحتوي على اعتماديات Composer الخاصة بالتطبيق.

هل يجب رفع مجلد vendor إلى Git؟

في المشاريع الحديثة، لا تحتاج عادة إلى حفظ vendor داخل مستودع Git؛ لأنه يمكن إعادة إنشائه من خلال Composer اعتمادًا على ملفات المشروع.

ولهذا السبب يتم عادة استثناء المجلد من Git.

بعد تحميل المشروع على جهاز جديد، يمكن تشغيل:

composer install

لتثبيت الاعتماديات المطلوبة.

وهذا من الأمور التي ستتعلمها بشكل أكبر عندما نتحدث عن Git ونشر التطبيقات.

ملف artisan

في جذر المشروع ستجد:

artisan

وهو ملف مهم جدًا في Laravel.

من خلال Artisan تستطيع تنفيذ عدد كبير من أوامر Laravel.

مثلًا:

php artisan list

لعرض الأوامر المتاحة.

ويمكنك استخدام:

php artisan route:list

لعرض Routes الموجودة في التطبيق.

كما يمكن إنشاء Controller باستخدام:

php artisan make:controller ArticleController

وإنشاء Model باستخدام:

php artisan make:model Article

وسنستخدم Artisan باستمرار طوال هذا الكورس.

ملف composer.json

الملف:

composer.json

يحتوي على تعريفات مهمة تخص مشروع PHP واعتماديات Composer.

عندما يقرأ Composer هذا الملف، يعرف الحزم التي يحتاج إليها المشروع.

ستجد عادة قسمًا مثل:

{
    "require": {},
    "require-dev": {}
}

القسم الأول يحتوي على الاعتماديات المطلوبة لتشغيل التطبيق.

أما require-dev فيحتوي على الاعتماديات المستخدمة أثناء التطوير والاختبار.

سنستخدم Composer كثيرًا في المراحل القادمة.

ملف composer.lock

قد تجد أيضًا:

composer.lock

هذا الملف يحتفظ بالإصدارات الدقيقة للحزم التي تم تثبيتها.

وجوده مهم جدًا في المشاريع لأنه يساعد على جعل بيئة التطوير متطابقة قدر الإمكان بين أجهزة أعضاء الفريق والخوادم.

عندما يعمل أكثر من مطور على المشروع، من المهم أن يستخدموا نفس الإصدارات المحددة للاعتماديات.

ملف package.json

بجانب منظومة PHP، توجد منظومة JavaScript.

وهنا يأتي:

package.json

هذا الملف يحتوي على معلومات وحزم JavaScript التي يستخدمها المشروع.

عندما تقوم بتنفيذ:

npm install

يقرأ NPM هذا الملف ويقوم بتثبيت الحزم المطلوبة.

وهذا هو السبب في وجود مجلد:

node_modules/

بعد تثبيت حزم JavaScript.

مثل vendor، لا تحتاج عادة إلى رفع node_modules إلى Git؛ لأنه يمكن إعادة إنشائه باستخدام:

npm install

ملف .gitignore

ستجد غالبًا ملفًا يسمى:

.gitignore

هذا الملف يخبر Git بالملفات والمجلدات التي يجب عدم تتبعها.

يمكن أن يحتوي على عناصر مثل:

/vendor
/node_modules
.env

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

ملف .env.example

قد تجد أيضًا:

.env.example

وهو نموذج للإعدادات المطلوبة.

الفكرة أن المطور لا يضع القيم السرية الفعلية داخل هذا الملف.

بدلًا من ذلك، يمكن للشخص الذي يقوم بإعداد المشروع إنشاء:

.env

ووضع القيم المناسبة لبيئته.

وهذه طريقة مفيدة جدًا عند مشاركة المشروع مع مطورين آخرين.

كيف تتحرك داخل المشروع؟

الآن بعد أن تعرفنا على أهم المجلدات، يجب أن نطور عادة مهمة جدًا.

عندما تريد تنفيذ مهمة، اسأل نفسك:

أين يجب أن أضع هذا الكود؟

على سبيل المثال:

إذا أردت إنشاء Route:

routes/web.php

إذا أردت إنشاء Controller:

app/Http/Controllers/

إذا أردت إنشاء Model:

app/Models/

إذا أردت إنشاء Migration:

database/migrations/

إذا أردت إنشاء View:

resources/views/

إذا أردت قراءة Logs:

storage/logs/

إذا أردت تنفيذ أمر Laravel:

php artisan ...

هذا التفكير سيجعل تعلم Laravel أسهل بكثير.

مثال عملي: أين نضع ملفات نظام المقالات؟

لنفترض أننا سنبني موقع مقالات.

نحتاج إلى:

• Model للمقال.
• Controller للمقال.
• Migration لجدول المقالات.
• View لعرض المقال.
• Route للوصول إلى المقال.

أين نضع كل واحد؟

Model

app/Models/Article.php

Controller

app/Http/Controllers/ArticleController.php

Migration

database/migrations/xxxx_xx_xx_create_articles_table.php

View

resources/views/articles/index.blade.php

Route

routes/web.php

لاحظ كيف تم توزيع المشروع.

كل عنصر له مكان واضح.

وهذه هي إحدى نقاط قوة Laravel.

كيف يعمل الطلب داخل المشروع؟

من المفيد الآن أن نربط ما تعلمناه في الدرس الأول والثالث معًا.

عندما يدخل المستخدم إلى عنوان معين في الموقع، يصل الطلب إلى التطبيق.

يمكن تبسيط الفكرة كالتالي:

المستخدم
   ↓
Web Server
   ↓
public/index.php
   ↓
Laravel
   ↓
Route
   ↓
Controller
   ↓
Model
   ↓
Database
   ↓
Controller
   ↓
View
   ↓
Response
   ↓
المستخدم

هذه ليست كل التفاصيل الداخلية لدورة الطلب، لكنها صورة تعليمية ممتازة للمبتدئ.

وفي مراحل متقدمة سنتعلم أن Laravel يمتلك Request Lifecycle أكثر تفصيلًا يتضمن Bootstrap وMiddleware وService Container وغيرها.

هل يمكنني تغيير بنية Laravel؟

نعم، Laravel لا يجبرك على الالتزام الحرفي بكل مكان لكل ملف.

لكن في بداية تعلمك، لا أنصحك بتغيير البنية الافتراضية دون سبب.

السبب بسيط.

عندما تتبع البنية القياسية:

• سيكون من السهل فهم الشروحات.
• سيكون من السهل التعاون مع المطورين الآخرين.
• سيكون من السهل قراءة مشاريع Laravel.
• ستستفيد بشكل أفضل من أدوات Artisan.
• ستعرف أين تبحث عن الملفات.

وبعد أن تكتسب خبرة جيدة، يمكنك اتخاذ قرارات تنظيمية أكثر تقدمًا.

أخطاء شائعة في التعامل مع بنية المشروع

وضع ملفات PHP داخل public

لا تضع منطق التطبيق وملفات PHP الداخلية داخل public لمجرد أن هذا المجلد متاح للمتصفح.

المكان الصحيح يعتمد على نوع الملف ووظيفته.

تعديل ملفات vendor

لا تقم بتعديل:

vendor/

يدويًا.

إذا كانت هناك مشكلة في حزمة، تعامل معها من خلال Composer.

وضع كلمات المرور داخل الكود

لا تكتب بيانات قاعدة البيانات أو مفاتيح الخدمات داخل Controllers أو Models.

استخدم .env والإعدادات المناسبة.

حذف ملفات لا تعرف وظيفتها

قد ترى ملفًا وتعتقد أنه غير مهم.

لا تحذفه لمجرد أنك لا تعرف وظيفته.

إذا لم تكن متأكدًا، اتركه كما هو وابحث عن وظيفته.

الاعتماد على شروحات قديمة

من أكثر الأخطاء شيوعًا أن تشاهد شرحًا قديمًا لـ Laravel وتفترض أن بنية المشروع الحالية مطابقة له.

الإصدارات الحديثة من Laravel شهدت تغييرات في البنية الافتراضية وطريقة إعداد بعض المكونات.

لذلك يجب دائمًا الانتباه إلى إصدار Laravel الذي تستخدمه.

تمرين عملي

افتح مشروع Laravel الذي أنشأته في الدرس السابق، ثم حاول الإجابة عن الأسئلة التالية.

السؤال الأول

أين يوجد ملف Routes الأساسي لتطبيق الويب؟

الإجابة:

routes/web.php

السؤال الثاني

أين توجد Models؟

الإجابة:

app/Models/

السؤال الثالث

أين توجد Controllers؟

الإجابة:

app/Http/Controllers/

السؤال الرابع

أين توجد Views الخاصة بـ Blade؟

الإجابة:

resources/views/

السؤال الخامس

أين توجد Migrations؟

الإجابة:

database/migrations/

السؤال السادس

أين توجد ملفات Logs؟

الإجابة:

storage/logs/

السؤال السابع

ما المجلد الذي يحتوي على اعتماديات Composer؟

الإجابة:

vendor/

السؤال الثامن

ما الملف الذي يحتوي على إعدادات البيئة؟

الإجابة:

.env

إذا استطعت الإجابة عن هذه الأسئلة دون الرجوع إلى الدرس، فقد بدأت بالفعل في فهم بنية Laravel.

ماذا تعلمنا في هذا الدرس؟

في هذا الدرس تعرفنا بالتفصيل على البنية الأساسية لمشروع Laravel.

تعلمنا أن:

• app يحتوي على الجزء الأساسي من كود التطبيق.
• app/Http يحتوي على Controllers وMiddleware وForm Requests.
• app/Models يحتوي على Eloquent Models.
• app/Providers يحتوي على Service Providers.
• bootstrap مسؤول عن تهيئة Laravel وملفات Cache الخاصة به.
• config يحتوي على إعدادات التطبيق.
• database يحتوي على Migrations وFactories وSeeders.
• public هو نقطة الدخول العامة للتطبيق ويحتوي على index.php.
• resources يحتوي على Views والموارد المصدرية للواجهة.
• routes يحتوي على تعريفات Routes.
• storage يحتوي على Logs وCache وملفات ينشئها التطبيق.
• tests يحتوي على الاختبارات.
• vendor يحتوي على اعتماديات Composer.
• .env يحتوي على إعدادات البيئة.
• artisan هو واجهة أوامر Laravel.
• composer.json يعرّف اعتماديات PHP.
• package.json يعرّف اعتماديات JavaScript.

كما تعلمنا أن أهم شيء ليس حفظ أسماء المجلدات فقط، وإنما معرفة أين نضع كل نوع من الأكواد.

بنية Laravel قد تبدو معقدة عند رؤيتها لأول مرة، لكنها في الحقيقة منظمة بطريقة تجعل تطوير التطبيق أسهل.

كل مجلد له وظيفة محددة، وكل نوع من الملفات له مكان منطقي.

ومع استمرارك في الكورس ستتعامل مع هذه المجلدات بشكل يومي، وستبدأ في حفظ أماكنها بشكل طبيعي دون الحاجة إلى محاولة حفظها بالقوة.

والآن أصبحت تعرف أين توجد Routes وControllers وModels وViews وMigrations وملفات الإعدادات والتخزين.

في الدرس الرابع سنبدأ أول جزء عملي حقيقي في كتابة Laravel، وسنتعلم Routing في Laravel، وسننشئ أول Route بأنفسنا، ونفهم الفرق بين أنواع الطلبات مثل GET وPOST، وكيف نمرر البيانات داخل الرابط، وكيف نربط Route بـ Controller.

وهنا ستبدأ الصورة التي تعلمناها في هذا الدرس بالتحول إلى كود حقيقي.