توجه! Symfony در برخورد اول شاید اعتیاد آور باشد! فصل چهارم

توجه! Symfony در برخورد اول شاید اعتیاد آور باشد! فصل چهارم

فصل چهارم – معماری

 

شما حالا قهرمان هستید! چه کسی می توانست تصور کند هنوز هم بعد از گذشت سه فصل سیمفونی را دنبال می کنید؟ مطمئن باشید تلاش شما همراه با پاداش خواهد بود. سه فصل اول بیش از حد به معماری فریم ورک نپرداخته بود. از آنجایی که Symfony از دیگر فریم ورک ها متمایز است، اجازه دهید شیرجه به درون معماری آن بزنیم.

 

درک ساختار دایرکتوری

 

ساختار دایرکتوری یک برنامه سیمفونی نه تنها انعطاف پذیر است بلکه پیشنهاد می شود از ساختار زیر استفاده شود:

 

app/

پیکربندی برنامه، قالب ها و ترجمه ها.

 

bin/

فایل های اجرایی (مثل bin/console).

 

src/

کدهای PHP پروژه.

 

tests/

تست‌های خودکار (به عنوان مثال تست‌های Unit).

 

var/

تولید فایل‌ها (مثل cache، log …)

 

vendor/

افزونه های که بطور جداگانه نصب می شوند

 

web/

دایرکتوری ریشه برنامه وب.


 

 

دایرکتوری web/

 

دایرکتوری ریشه محلی برای تمام فایل‌های عمومی مثل تصاویر، سی اس اس، جاوا اسکریپت است. همچنین جایی است که کنترولرها در آن ساکن هستند، به عنوان مثال کنترولر نهایی در بصورت زیر خواهد بود:

 

 

controller ابتدا با استفاده از کلاس کرنل برنامه را آماده سازی می کند. آنگاه یک شی Request با استفاده از متغیرهای سراسری PHP ایجاد می کند و آن را به کرنل ارسال می کند. آخرین مرحله این است که محتوای برگشت داده شده توسط کرنل، به کاربر ارسال می شود.

 

دایرکتوری app/

کلاس AppKernel فایل اصلی برای پیکربندی برنامه است که در دایرکتوری app/ ذخیره می شود.

 

این کلاس با دو متد پیاده سازی شده است:

  • registerBundles()

آرایه‌ای از تمام بسته های نرم افزاری که در سیمفونی به bundle معروف است بر می گرداند که در بخش بعدی توضیح داده می شود.

  • registerContainerConfiguration()

تنظیمات برنامه را بارگذاری می کند (بیشتر در ادامه خواهید دید).

 

بارگذاری بطور خودکار از طریق Composer صورت می گیرد، به این معنی که می توانید از هر کلاس PHP بدون انجام کاری استفاده کنید! تمام پلاگین‌ها یا وابستگی های برنامه (dependencies) در دایرکتوری vendor/ نگهداری می شوند، اما این فقط یک کنوانسیون است، شما مختار هستید تمام اینها را هر کجا که دوست دارید ذخیره کنید، بطور سراسری (global) بر روی سرور یا بصورت محلی (local) در پروژه خود.

 

درک سیستم Bundle

 

این بخش یکی از بزرگترین و قدرتمندترین ویژگی سیمفونی است، سیستم bundle. یک bundle همانند یک پلاگین در برنامه های دیگر است. بنابراین با این حال چرا به bundle معروف است و نه پلاگین؟ چون همه چیز در سیمفونی یک bundle است، از هسته‌ی فریم ورک تا کدهایی که برای برنامه خود می نویسید.

 

تمام کدهایی که برای برنامه خود می نویسید در bundleها سازماندهی می شوند. در سیمفونی می گویند، یک bundle مجموعه ای از فایل‌های سازمان یافته است (فایل‌های php، css، js، تصاویر) که در یک ویژگی خاص پیاده سازی شده است (بلاگ، فروم) که می تواند به سادگی بین توسعه دهندگان دیگر به اشتراک گذاشت.

 

باندل‌ها شهروندان درجه یک در سیمفونی هستند. این به شما انعطاف پذیری لازم برای استفاده از پکیج‌های از پیش ساخته شده در باندل‌های دیگر یا باندل‌های ساخته شده توسط شما را می دهد. این باعث می شود که به راحتی توانید ویژگی‌های برنامه خود را انتخاب و فعال کنید و هر طور که می خواهید آنها را بهینه سازی کنید.

 

و در پایان روز، برنامه شما همانند هسته خود فریم ورک مهم و ارزشمند خواهد بود.

 

در دایرکتوری src/ سیمفونی یک AppBundle تعریف کرده است که شاید بخواهید از آن برای شروع توسعه برنامه خود استفاده کنید. همچنین اگر نیاز دارید برنامه‌ی خود را به اجزای کوچک با قابلیت استفاده مجدد تقسیم کنید، می توانید bundle خود را ایجاد کنید.

 

ثبت یک Bundle جدید

 

یک برنامه بر پایه bundleهایی که در متد registerBundles() از کلاس AppKernel وجود دارد ساخته می شود. هر bundle دارای دایرکتوری خاص خود است که با یک کلاس Bundle تعریف می شود:

 

 

علاوه بر این درباره AppBundle صحبت شده است، توجه داشته باشید که کرنل، دیگر باندل‌هایی مثل FrameworkBundle و DoctrineBundle و SwiftmailerBundle و AsseticBundle که بخشی از سیمفونی هستند را فعال می کند.

 

تنظیمات یک Bundle

 

هر باندل می تواند از طریق فایل‌های که در قالب YAML، XML یا PHP نوشته می شود، سفارشی سازی شود. اجازه دهید نگاهی به تنظیمات پیشفرض سیمفونی بیدازیم:

 

 

هر یک از سرشاخه‌ها مثل framework، twig و swiftmailer تنظیمات خاص خود را مشخص می کنند. به عنوان مثال، framework تنظیمات FrameworkBundle را انجام می دهد، در حالی که swiftmailer تنظیمات SwiftmailerBundle را انجام می دهد.

 

هر محیط می تواند با ارائه فایل پیکربندی خاص خود تنظیماتی برای خود داشته باشد. به عنوان مثال، محیط dev فایل config_dev.yml را بارگذاری می کند، در حالی که تنظیمات اصلی در فایل config.yml قرار داده شده است و برای تغییر برخی از ابزارهای اشکال زدایی کاربرد دارد:

 

 

توسعه یک باندل

 

علاوه بر این می توان یک باندل را در باندل دیگر توسعه داد و این یک روش عالی برای سازماندهی و پیکربندی کدها است. به ارث بردن باندل‌ها به شما این اجازه را می دهد که هر بادل را در بادنل دیگر بازنویسی کنید، به عبارتی باندل را برای کنترلرها، قالب‌ها یا هر فایل دیگر آن سفارشی سازی کنید.

 

نام فایل‌های منطقی

 

وقتی می خواهید یک از یک bundle فایل دیگری را فراخوانی کنید، از الگو زیر استفاده کنید:

 

 

سیمفونی مسیر @BUNDLE_NAME را برای باندل مشخص می کند. به عنوان مثال، مسیر @AppBundle/Controller/DefaultController.php می تواند به src/AppBundle/Controller/DefaultController.php تبدیل شود، چون سیمفونی از آدرس حقیقی AppBundle با خبر است.

 

نام کنترلرهای منطقی

 

برای controllerهای نیاز است که از الگو زیر برای دسترسی به اکشن‌ها استفاده شود:

 

 

به عنوان مثال، AppBundle:Default:index اشاره به متد indexAction از کلاس AppBundle\Controller\DefaultController دارد.

 

توسعه باندل‌ها

 

اگر این کنوانسیون ها را دنبال کردید، بنابراین می توانید  از bundle inheritance برای سفارشی سازی یا بازنویسی controllerها یا teamplateها استفاده کنید. به عنوان مثال، شما می توانید یک باندل جدید به نام NewBundle داشته باشید که از AppBundle به ارث برده باشد. وقتی سیمفونی کنترلر AppBundle:Default:index را بارگذاری می کند، ابتدا کلاس DefaultController در NewBundle را اولویت قرار می دهد، اگر وجود نداشت انگاه سراغ AppBundle می رود. به این معنی که هر bundle می تواند تقریبا هر بخش از bundle دیگر را بازنویسی کند!

 

آیا حالا درک کردید چرا Symfony اینقدر انعطاف پذیر است؟ باندل‌ها را در برنامه خود به اشتراک بگذارید، آنها را بصورت local یا globall ذخیره کنید، در آخر انتخاب با شماست!

 

استفاده از Vendor

 

شاید عجیب به نظر برسد که برنامه به کتابخانه‌هایی که در دایرکتوری vendor/ ذخیره شده است وابسته است. شما هیچ وقت نباید به فایل‌های درون این دایرکتوری دست بزنید، چون شدیدا توسط Composer مدیریت می شود. این دایرکتوری در حال حاظر شامل کتابخانه‌های سیمفونی است، کتابخانه‌های SwiftMailer، Doctine، ORM، سیستم قالب بندی Twig و غیره و باندل‌ها است.

 

Cache و log

 

برنامه های سیمفونی می تواند شامل چندین فایل در فرمت‌های مختلف (YAML – XML – PHP) برای تنظیمات باشد.  بجای اینکه در هر بار درخواست جدید، این فایل‌ها را تجزیه و ترکیب کنیم، سیمفونی  از سیستم cache خود استفاده خواهد کرد. در واقع، تنظیمات برنامه فقط در اولین درخواست مورد پردازش قرار می گیرد و آنگاه بصورت کد ساده PHP در دایرکتوری var/cache/ ذخیره می شود.

 

در محیط توسعه، سیمفونی به اندازی کافی باهوش است که بتواند cache را در هر بار تغییر فایل بروز رسانی کند. اما در محیط product برای افزایش سرعت این مسئولیت شما خواهد بود که در هر بار تغییر کد، cache را پاک کنید. دستور زیر را اجرا کنید تا cache در محیط prod را پاک کند:

 

 

وقتی در حال توسعه یک برنامه تحت وب هستید، شاید اشکالاتی در برنامه رخ دهد. فایل‌های log در دایرکتوری var/logs/ ذخیره می شوند و تمام چیزها درباره درخواست‌ها در آنها گزارش می شود. این فایل‌ها باعث می شوند مشکلات را سریع رفع کنیم.

 

استفاده از خط فرمان

 

هر برنامه با یک ابزار اینترفیس خط فرمان (bin/console) که در حفط برنامه به ما کمک می کند می آید. این ابزار دستوراتی را ارائه می دهد که بهره وری شما را با خودکار سازی وظایف خسته کننده و تکراری افزایش می دهد.

 

این دستور را بدون آرگومان اجرا کنید:

 

 

برای یادگیری بیشتر می توانید از گزینه --help برای مشاهده دستورات موجود استفاده کنید:

 

 

سخن پایانی

 

شاید بگویید من دیوانه هستم، اما بعد از خواندن این بخش، به راحتی می توانید در چیزهای جدید با Symfony ایجاد کنید. همه چیز در سیمفونی به میل شما طراحی شده است. بنابراین، در صورت تمایل می توانید نام فایل‌ها و دایرکتوری‌ها را تغییر دهید.

 

تور سیمفونی ما در اینجا به پایان می رسد. شما هنوز به چیزهای بیشتر برای یادگیری نیاز دارید تا به یک استاد سیمفونی تبدیل شوید. آماده اید که به این موضوعات بپردازید؟ دیگر مستندات سیمفونی را مطالعه کنید.