معماری MVC در PHP

با سلامی دوباره خدمت شما عزیزان

این مبحث رو میخواییم اختصاص بدیم به mvc در  PHP و اولین چیزی که باید بگم تا این مقاله رو نخوندین مستقیم نرین سراغ تمرین و کد ،چون اگه درک صحیحی از mvc نداشته باشین ولی کدهاشو بلد باشین بازم نمی تونین تحت این معماری پروژه پیاده کنین پس لذا اول خوب این مقاله رو بخونین بعد شروع کنین به خوندن تمرین ها و آخر سر تبدیل بشین به یک برنامه نویس MVC

خب شروع کنیم ، MVC چیه ؟

MVC مخفف کلمات :

Model

View

Controller

به چه دردی میخوره ؟ :

تو یکی از زمون ها بازم چندتا برنامه نویس بیکار نشستن فکر کردن و آخر سر به این نتیجه رسیدن که قسمت طراحی و کد برنامه باید از هم جدا پس بعد کلی فکر  آخر سر MVC رو کشف کردن .

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

خب دقت کرده باشین سخته که یه خانوم هم زمان هم صورتش رو بزک کنه یا بده دست آرایشگر و از طرفی هم بره پیش روان پزشک یا دکتر و کنار اینها هم بره پیش پیشوای مذهبی ، MVC هم دقیقاً مثل این خانومه یعنی میگه قسمت کد و برنامه نویسی رو از قسمت طراحی جدا کنین تا کارتون راحت باشه.

تو این نوع معماری نرم افزار شما با سه تا چیز کار دارین :

View :

این قسمت همون صورت خانومه مثال قبله یعنی پنجره هایی که با کاربر ارتباط دارن فرمهای ….. دکمه ها ، جعبه های متنی و…. خلاصه هرچیزی که جلوی چشم کاربره و از طریق اونا میتونه درخواست بفرسته یا پردازش اطلاعات و نتیجه درخواست رو ببینه .

Model :

این قسمت همون قسمت ارتباط با پایگاه داده هست یعنی این قسمت به طور مستقیم با database ارتباط برقرار میکنه و داده وارد میکنه یا خارج میکنه .(تو خط مقدمه)

Controller :

 خب این قسمت هم خدمات چی ما هست ، کار این قسمت خیلی شبیه دلال و خدمات رسان های جبهه جنگه ، این قسمت تقریبا یه واسطه بین View و Model هست و رابطه میان این دوتاست ، این قسمت به Model درخواست میفرسته که مثلاً فلان داده ها رو از پایگاه داده بردار ،بعد داده هایی که Model از پایگاه داده فرستاده به View بفرسته ، یا وقتی کاربر درخواستی رو میکنه وظیفه Controller هست که این درخواست ها رو مدیریت کنه و پاسخ مناسب رو پیدا کنه بفرسه.

یک فرم یا … رو در نظر بگیرین : فرم View ماهست و جلوی چشم کاربره ،کاربر از طریق فرم با برنامه ارتباط برقرار میکنه ، کاربر وقتی روی فرم کلیک میکنه یه درخواست میفرسته ،کنترلر میاد این درخواست رو پردازش میکنه مثلاً کاربر میخواد رمز عبورش رو عوض کنه وقتی این درخواست رو میده View یا همون فرم اطلاعات رو میفرسته به Controller و کنتلر هم درخواست رو بررسی میکنه ،پس به Model درخواست میفرسته که دنبال نام کاربری و رمز عبور این کاربر بگرده و وقتی پیدا کرد نتیجه رو به کنتلر برگشت میده و کنتلر رمز عبور جدید رو با قدیم عوض میکنه و نتیجه کار رو که مثلاً رمز عبور با موفقیت شد رو به View میفرسته و View هم به کاربر نمایش میده .

خب واقعا مزیت این کار چیه ؟ این کار چند تا سود داره مثلاً :

طراح و برنامه نویس می تونند همزمان روی پروژه کار کنند.

مثلاً میخوایین پایگاه داده پروژه رو عوض کنید و با یه پایگاه داده دیگه کار کنید و خوبیش اینجاس که دیگه لازم نیست تو کل تک به تک های پروژه دنبال کدهای پایگاه داده بگردین و فقط Model رو ویرایش میکنین !

مزیت MVC زیاده و از حوصله منم خارجه بگم .

تو معماری MVC متاسفانه همه اتفاق نظر ندارند : خیلی ها عقیده دارند Model میتونه با View ارتباط داشته باشه و وقتی داده ها رو تو پایگاه داده ویرایش کرد یا … میتونه نتیجه رو یا داده ها رو به View ارجاع بده ، بعضی ها هم بر عکس عقیده دارن که تحت هیچ شرایطی Model نباید با View ارتباط داشته باشه و فقط باید با Controller ارتباط داشته باشه که بنظر من این کار یکم عجیبه چون وقت پیاده کردن پروژه دوباره باید برای داده برگشتی تو Controller کدبزنی تا به View بفرسته و برای View هم باید دوباره کد زد تا به کاربر نمایش بده و دردسر زیاد داره !(این گروه میگن Model باید کور باشه )

یه فروشگاه بزرگ رو با انبار در نظر بگیرین : فروشنده جلو هست و با مشتری ارتباط داره و تقریبا View ما هست ، یه کارگر هم انبار هست که جنس های انبار رو جابه جا میکنه ،یه کارگر دیگه هم هست که بین این دوتاست و وقتی کارگر انبار جنسی رو بیرون میاره اون فوراً جنس رو تحویل فروشنده میده تا تحویل مشتری بده خب پس طرز کار اینطوریه :

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

فروشنده همون View ما هست که با کاربر ارتباط داره

کارگار انبار همون Model ما هست که تو انباره و انبار هم پایگاه داده ما هست

کنترلر همون کارگر واسط بین فروشنده و کارگره انباره و وظیفش اینه درخواست های فروشنده رو به کارگر انبار بگه

وقتی یه مشتری برای مثال کفش سایز ۳۸ میخواد فروشنده فوراً به کارگر واسط میگه برو انبار به انباردار بگو کفش سایز ۳۸ پیدا کنه ، انبار دار فوراً دنبال کفش میگرده و نتیجه کار رو به کارگر واسط میگه و کارگر واسط هم میره فوراً به فروشنده میره و فروشنده هم نتیجه رو به کاربر نشون میده.

معماری MVC دقیقا شبیه مثال بالا هست و کل فروشگاه میشه یه برنامه تحت MVC

مزیتش اینه اگه شما با فروشنده مشکل دارین لازم نیست کل مغازه رو دستکاری کنید فقط فروشنده رو عوض کنید .اگه انبارتون خراب شده میتونین راحت برین انبارداری و تمامش رو عوض کنید بدون اینکه به سایر کدهاتون چیزی بشه و…. الی آخر مزیت داره .

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

خب دوستان امیدوارم لذت برده باشین و اگه مشکلی هم پیش اومد در خدمتتون هستم ، در آموزش های بعدی یه پروژه واقعی رو باهم پیاده میکنیم تا نحوه کار کردن این معماری رو بفهمیمV

3 thoughts on “معماری MVC در PHP

  1. سلام دوست عزیز عالی بود.ولی به نظر من هم نباید viwe با مدل ارتباط داشته باشه درسته کدزنی یکم بیشتر میشه ولی یکپارچگی کدها حفظ میشه و کدها قانون مندتر میشن

    • سلام با تشکر
      ویو اگر با مدل ارتباط داشته باشه اون وقت کلاً منطق این معماری منظورم کنترلر عملاً بی فایده میشه و تو داکیومنت های گوگل هم در مورد این معماری به همین نکته اشاره می کنن ولی هرکس طوری پیاده کرده و نمیشه در کل گفت باید یه جور خاص باشه ولی اگر بخواییم سخت گیری کنیم و دقیقا تو شیوه ای که تیم اسمل تاک برای اولین بار این معماری رو پیاده کرد ماهم دقیقاً همون طور پیاده کنیم مدل نباید با ویو تو ارتباط باشه ، البته الان بازم این معماری تو بعضی پروژه ها زیر ساختش کلاً فرق میکنه مثلاً تو فریم ورک phoenix علاوه بر ویو چیز دیگه ای به اسم تمپلیت هم داریم که واقعاً محشره ، به هرحال اگر خدا عمری بده بازم ادامه میدم و این معماری رو در حد حرفه ای و بازار کار پیاده می کنم امیدوارم مورد استفادتون قرار بگیره

دیدگاه‌تان را بنویسید: