استفاده از Doctrine ORM در Laravel به جای Eloqunet

Doctrine ORM از  نسخه دوم معماریشو از نوع ActiveRecord به DataMapper تغییر داد. اگه نمیدونید فرق این دو تا چیه این بلاگ پست رو بخونید. همونطور که میدونید لاراول به صورت پیشفرض از  ORM بسیار خوب و قوی Eloquent که توسط تیم همین فریمورک طراحی شده استفاده میکنه که معماریش ActiveRevordایه ولی اگه شما هم مثل من به سرتون زده که از یه ORM دیگه استفاده کنید، ادامه بدید به خوندن این پست وگرنه فکر نمیکنم فایده‌ای داشته باشه براتون.

من از Doctrine تو فریمورک‌های Yii و Symfony قبلا استفاده کردم و تقریبا بهش مسلطم واسه همین قصدم اینه که به دلایلی مثل کد تمیزتر و جدا بودن لایه Data Persistence از لایه Domain و … از این ORM توی پروژه‌های لاراولیم هم استفاده کنم. خب برای این کار چند راه داریم یکیش و سخت‌ترینش اینه که Doctrine رو با Composer نصب کنیم و خودمون شروع کنیم به integrate کردنش با لاراول. خب وقتی قبلا افرادی بودن که همین قضیه به فکرشون رسیده و این کارو انجام دادن، چرا باید دوباره خودمون  چرخو از اول اختراع کنیم؟ LaravelDoctrine یه پکیجیه که این کارو برامون آسون میکنه و برای داشتن Doctrine روی لاراول به ترتیب زیر عمل میکنیم:

نصب Doctrine

ابتدا پکیج  laravel-doctrine/orm رو با توجه به نسخه لاراولمون نصب میکنیم. من خودم از لاراول نسخه ۵٫۱٫* استفاده میکنم، نسخه‌ای که باید از این پکیج نصب کنم به این ترتیبه:

شما هم میتونید با توجه به نسخه لاراولتون، نسخه مناسب خودتونو نصب کنید:

Screenshot from 2016-07-25 12-57-31

بعد از اینکه نصب شد، Service Provider این پکیج را به آرایه Providerهامون توی فایل config/app.php  اضافه میکنیم:

در مرحله بعدی باید فایل تنظیمات laravel-doctrine/orm  رو با فرمان زیر به دایرکتوری configs  اضافه میکنیم:

بعد اینکه این کارها رو انجام دادیم، تقریبا همه چی آماده س برای شروع، فقط قبلش یه دایرکتوری برای Entity هامون درست میکنیم که همینجوری توی دایرکتوری app  ول نباشن، من دایرکتوری app/Entities  رو دست کردم و بعدش توی فایل config/doctrine.php ، توی خط ۳۲، base_path('app')  رو به base_path('app/Entities')  تغییر دادم.

ایجاد Entity

برای مثال من میخوام Entity کاربر درست کنم، برای این منظور، یه فایل به نام User.php توی دایرکتوری app/Entities درست میکنم و Mappingشو به صورت Annotation بهش میدم. توی داکترین به چند شکل میشه Mapping تعریف کرد، Annotation , XML, YAML , PHP که به صورت پیشفرض من از Annotation استفاده  کردم. هر User من میتونه بینهایت BlogPost داشته باشه که اونو هم داخل کلاس نوشتم. توجه داشته باشید که هر Entity میتونه مستقیم یه  جدول از دیتابیس باشه یا نباشه.

در ادامه کلاس BlogPost رو هم ایجاد میکنم:

تا اینجای کار، ما فقط دو تا کلاس ساده PHP ایجاد کردیم و با دیتابیس کاری نداشتیم حالا برای ایجاد جداول دیتابیسمون یا اعمال تغییرات باید دستور زیر رو توی خط-فرمان اجرا کنیم:

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

 

کار با Entity ها

در Doctrine برای کار با Entity ها ما به طور پیشفرض با چند ابزار مواجه هستیم، Entity Manager, Entity Repository و Query Builder. که به وسیله Entity Manager همه عملیات‌ رو روی Entity  انجام میدیم. Entity Manager ابزارهای لازم برای کوئری گرفتن از دیتابیس و ایجاد و ویرایش بر روی دیتابیس رو بر عهده داره. در ادامه یه مثال میزنم که خوب متوجه بشید:
برای ایجاد یک کاربر و یه سری بلاگ‌پست کد زیر رو مینویسیم:

همونطور که میبینید، تو کد بالا با Entity ها مثل Objectهای معمولی PHP رفتار کردیم و دقیقا هم کار و رفتارشون  همینه و عملیات ارتباط با دیتابیس و ذخیره کردن و تبدیل محتوای آبجکت‌ها توسط EntityManager مدیریت میشه.

حالا برای دریافت اطلاعات از دیتابیس باید از Repository یا Query Builder استفاده کنیم. هر Entity میتونه Repository مخصوص به خودشو داشته باشه یا اینکه از EntityRepository پیشفرض Doctrine استفاده میکنیم. در هر صورت کاری که باید بکنیم اینه:

متغیر $manager رو از Container باید بگیریم که یا باید کلاس EntityManager رو inject کنیم تو متد یا کنترلرمون یا اینکه باید از به وسیله app('em')  یا app(EntityManager::calss)  میتونیم همه جا داشته باشیمش.

توصیه میکنم برای آشنایی بیشتر مستندات Doctrine ORM رو بخونید. در آخر اگه سوالی داشتید و میتونستم جواب بدم، خوشحال میشم کمکتون کنم.

 

 

ایجاد slug با قابلیت پشتیبانی از زبان فارسی در لاراول

برای داشتن urlهای تمیز و  SEO Friendly در برنامه‌های تحت وب راههای زیادی وجود داره. در لاراول به صورت پیشفرض می‌تونید به روش زیر slug یا نامک از رشته‌هاتون درست کنید:

 

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

Eloqunet Sluggable یک پیکج برای تولید تولید اتوماتیک slug در لاراول می‌باشد که میتونید با مراجعه به صفحه گیت‌هاب این پکیج با اون روش نصبش آشنا بشید.

بعد از نصب و ایجاد تنظیمات مربوطه می‌تونید توی مدل‌هاتون ازش استفاده کنید . روش کار هم به این صورته که شما به طور فرض یک مدل دارید با نام Post. خب باید مدلتون یه چیزی شبیه زیر باشه:

 

بعد از نصب پکیج مربوطه فقط کافیه مدلتونو به شکل زیر تغییر بدید:

 

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

 

خب تا اینجای کار، همه چیز مرتبه ولی یه مشکل بزرگ وجود داره و اون هم عدم پشتیبانی این پکیج و متد Str::slug() از زبان‌های یونیکد مثل فارسیه و این یعنی این پکیج و متد به درد ما نمی‌خورن. ولی باز هم راه حل وجود داره که به این ترتیبه:

ابتدا تنظیمات پکیج را publish می‌کنیم تا از فولدر config پروژه‌مون بهش دسترسی داشته باشیم و در هنگام به‌روزرسانی پکیج، تنظیماتمون باقی بمونه. برای این کار دستور زیر رو توی ترمینال و در دایرکتوری ریشه پروژه‌تون وارد کنید:

 

حالا اگه به فولدر app/config/packages/cviebrock/eloquent-sluggable برید فایل تنظیمات با نام config.php اونجا قرار داره.

حالا اگه فایل تنظیماتو باز کنید میبینید که گزینه‌های مختلفی برای اعمال کردن داره مثل unique که مشخص می‌کنید که slugهاتون در دیتابیس یکتا باشند یا نه که یکتا بودنشون تو آدرس‌دهی میتونه خیلی کمک کنه و یا گزینه on_update که مشخص می‌کنید آیا نامک در هنگام به روزرسانی رکورد به روزرسانی بشه یا نه که پیشنهاد می‌کنم اینو به true تغییر بدید.

یک گزینه دیگر وجود داره به نام method که میتونید در این گزینه متد و یا تابع دلخواهی که میخواهید slugهاتون بر اساس اون ساخته بشن رو تعریف کنید. به صورت پیش‌فرض Eloquent-sluggable از متد Str::slug() برا ساختن نامک استفاده می‌کنه که مشکلشو با زبان فارسی فهمیدیم چیه.

برای پشتیبانی از زبان‌های یونیکد فقط کافیه که متد زیر را به اون گزینه نسبت بدید و فایل config.php رو save کنید. بعد از اون به راحتی میتونید برید دنبال بقیه کارهاتون 😉

 

اینو بگم که من این متد رو از یکی از کتابخونه‌های فریمورک CakePHP برداشتم و با کمی تغییر تو اینجا قابل استفاده‌ش کردم.

پیاده‌سازی Repository Pattern در لاراول

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

در لاراول با استفاده از کتابخونه‌های قوی کارتون خیلی سرعت دارهو به راحتی پیش میره ولی بعضی موقع این راحتی کار دستتون میده. به عنوان مثال به کد زیر دقت کنید:

 

تو کد بالا ما یه کنترلر Post داریم و یه متد index که میشه صفحه اصلی کنترلرمون و توش با استفاده از مدل Post تمام رکورد‌ها رو ریختیم داخل یه متغیر و اونو پاس دادیم به View مون. تا اینجای کار، لذت بخش و آسون بود.

مشکل کجاست؟

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

یکی دیگه از مشکلات هم برمیگیرده به زمانی که بخواهیم نوع دیتابیسمونو عوض کنیم. مثلن بخواهیم از mongoDB به جای Mysql یا هر نوع دیتابیس از نوع Sql، استفاده کنیم. خب، توی استفاده از انواع Sql دیگر مثل SqlServer یا Postgesql نباید مشکلی باشه و نیازی نیست کدمونو تغییر بدیم ولی اگر به mongoDB بخواهیم کوچ کنیم مجبوریم تمام قسمت‌های کدمونو بازنویسی کنیم که این به دور از اصول توسعه سریع و تمیزه.

راه حل چیه؟

یکی از بهترین راه‌حل ها استفاده از Repository ها برای جدا کردن مدل‌ها از کنترلر‌هامون و مدیریت Dependency Injectionهاست. خب اول باید ببینیم Repository چی کار می‌کنه؟ Repositoryها میان یه واسطی میشن به بخش دیتابیس و کنترلرهامون و مثل یه تونل و فیلتر عمل می‌کنن تا ما از یک نوع کدنویسی و استاندارد برای ارتباط با پایگاه‌های داده اعم از (Redis, Sql, NoSql) استفاده کنیم.

به طور کلی Repositoryها به معنای ارتباط دهنده بین دو چیز هستند.

اگر به واژه رابط یا واسط توجه کرده‌باشد درمی‌یابید که Repository چیزی نیست جز interfaceها. بله، ما به کمک یکی از امکانات شی‌گرایی برای حل این مشکلات استفاده می‌کنیم.

حالا کد بالا رو می‌خواهیم بازنویسی کنیم:

ابتدا یک Repository برای Post ایجاد می‌کنیم:

 

سپس میاییم یک کلاس دیگر که از این interface ارث برده را ایجاد می‌کنیم: (توجه داشته باشید تمام کلاس‌هایی که از interfaceها implement می‌شوند باید تمام متدهایی که در interface نام برده شده‌اند‌ را داخل خودشون پیاده‌سازی کنند:

ما یک کلاس برای کار با انواع دیتابیس Sql ایجاد می‌کنیم و همونطور که میدونید برای این کار از کتابخونه Eloqunet لاراول استفاده می‌کنیم:

 

حالا کنترلرمونو بازنویسی می‌کنیم:

 

همونطور که میبینید دیگه کنترلر ما براش فرق نمیکنه که از چه نوع دیتابیسی استفاده کنه. ما به راحتی می‌تونید کلاس مربوط به اونو بنویسیم و با استفاده از Ioc Container لاراول، اونو به عنوان مدلمون معرفی کنیم.

چیزی که تو این پست نوشتم یه خورده خورده کاری داره مثل bind کردن کلاسمون به interface تا بتونیم تو پروژه‌هامون ازش استفاده کنیم که به صورت تفصیلی تو پست‌های آینده در موردش صحبت می‌کنم. فقط میخواستم یه دیدی از این کار داشته باشید.