PDA

View Full Version : ارتباطات در معماری MVC



H:Shojaei
یک شنبه 04 آبان 1393, 20:23 عصر
با سلام...
هنوز که هنوزه این مشکل هست که کدوم یکی درسته؟؟(البته در نمایش اطلاعات به کاربر نه ارسال اطلاعات توسط کاربر)
این که مدل با ویو در ارتباط مستقیم هست ؟؟
یا نه مدل توسط کنترلر باید با ویو ارتباط داشته باشه حتما؟؟

من اوایل که بر پایه این معماری تو یه فریمورک کار میکردم اطلاعات رو میفرستادم به کنترلر تو کنترلر یه چندتا تابع اعمال میشد واسه فیلتر اطلاعات واسه نمایش بعد نمایش داده میشد...

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

حالا واقعا کدوم روش بیس کار این معماری هست؟؟
میدونم با هر دو روش میتونیم کار کنیم و مشکلی هم نیست ولی میخوام به لحاظ تئوری دقیقا بدونم کدوم درسته؟؟

hamedarian2009
یک شنبه 04 آبان 1393, 21:24 عصر
من یه مقاله از دانشگاه اوهایو در مورد MVC خوندم اونجا به این نتیجه رسیده بهتره View با Model ارتباط مستقیم داشته باشه
124985

124986
اما در جاهایی هم گفتن نه نمیشه ارتباط مستقیم داشته باشی http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter
ولی در کل فکر میکنم بستگی به اون حالت داره مثلا یه موقع اصلا نیازی به کنترل داده و فیلتر نداری پس میتونی مستقیم با مدل ارتباط داشته باشی

arash691
یک شنبه 04 آبان 1393, 21:59 عصر
یه سوالی که پیش میاد اینه که اگر داده از طرف db نباشه چی ؟ مثلا" شما باید یه مقداری که تو session ذخیره کردی رو میخوای به کاربر نشون بدی ... اونوقت چی ؟ بعدش تو کجا چک کنی session مقدار گرفته یا نه ؟ تو کنترلر یا view ?

H:Shojaei
یک شنبه 04 آبان 1393, 22:06 عصر
بحث اینجاست که تو وب نیازی نیست کنترلر این وسط فقط یه فیلتر اطلاعات واسه نمایش کوچولو همینو بس غیر از اینه؟؟
کاربر درخواست رو میفرسته که میره به کنترلر بعد کنترلر بسته به نوع درخواست کاربر یه درخواست به مدل میفرسته بعد هم مدل اطلاعات رو که طبق نیاز کاربر تو کنترلر مشخص شده رو به ویو ارسال میکنه...
به نظر من دیگه نیازی نیست که اطلاعات برن کنترلر بعد برن به ویو با این کار کدهای سمت کنترلر الکی الکی میشه 1.5 برابر یعنی به ازای هر درخواست کاربر یه بار درخواست از کنترلر میره به مدل *باز از مدل برمیگرده میره به کنترلر* بعد توسط کنترلر میره به ویو واقعا این کار نیازه !!

Mohammadsgh
یک شنبه 04 آبان 1393, 22:12 عصر
یه سوالی که پیش میاد اینه که اگر داده از طرف db نباشه چی ؟ مثلا" شما باید یه مقداری که تو session ذخیره کردی رو میخوای به کاربر نشون بدی ... اونوقت چی ؟ بعدش تو کجا چک کنی session مقدار گرفته یا نه ؟ تو کنترلر یا view ?
تو مدل تعریف میشه.شما یه مدل میسازی برای اینکار که توش سیشن ایجاد میکنید

H:Shojaei
یک شنبه 04 آبان 1393, 22:15 عصر
یه سوالی که پیش میاد اینه که اگر داده از طرف db نباشه چی ؟ مثلا" شما باید یه مقداری که تو session ذخیره کردی رو میخوای به کاربر نشون بدی ... اونوقت چی ؟ بعدش تو کجا چک کنی session مقدار گرفته یا نه ؟ تو کنترلر یا view ?
میخواستم تو تاپیک اونور که پرسیدین جواب بدم حالا اینجا شد بهتر...
نه اصلا مشکلی نداره تو ویو میشه شرط هم داشت مثلا شما مشخواید ببینید کاربر آنلاینه یا نه که بگید خوش اومدی نیازی نیست کنترلر این کارو بکنه حتما تو خود ویو هم این کار انجام میشه...

Mohammadsgh
یک شنبه 04 آبان 1393, 22:18 عصر
بحث اینجاست که تو وب نیازی نیست کنترلر این وسط فقط یه فیلتر اطلاعات واسه نمایش کوچولو همینو بس غیر از اینه؟؟
کاربر درخواست رو میفرسته که میره به کنترلر بعد کنترلر بسته به نوع درخواست کاربر یه درخواست به مدل میفرسته بعد هم مدل اطلاعات رو که طبق نیاز کاربر تو کنترلر مشخص شده رو به ویو ارسال میکنه...
به نظر من دیگه نیازی نیست که اطلاعات برن کنترلر بعد برن به ویو با این کار کدهای سمت کنترلر الکی الکی میشه 1.5 برابر یعنی به ازای هر درخواست کاربر یه بار درخواست از کنترلر میره به مدل *باز از مدل برمیگرده میره به کنترلر* بعد توسط کنترلر میره به ویو واقعا این کار نیازه !!
ظاهرا شما با فریم ورکها زیاد کار نکردید.داده های مدل به کنترلر داده میشن و سپس از کنترلر به ویو.تو فریم ورک ci یه جستجویی درباره آرایه $data تو کنترلر بکنید متوجه منظورم میشید:چشمک:برای نمونه یی هم به این روش


$model = new Users('create');

مدل رو فراخوانی میکنه.اگه جایی مشکلی بود بگید:لبخندساده:

arash691
یک شنبه 04 آبان 1393, 22:25 عصر
میخواستم تو تاپیک اونور که پرسیدین جواب بدم حالا اینجا شد بهتر...
نه اصلا مشکلی نداره تو ویو میشه شرط هم داشت مثلا شما مشخواید ببینید کاربر آنلاینه یا نه که بگید خوش اومدی نیازی نیست کنترلر این کارو بکنه حتما تو خود ویو هم این کار انجام میشه...
امیدوارم همینی که شما میگی باشه :اشتباه: ... ممنون

H:Shojaei
یک شنبه 04 آبان 1393, 22:47 عصر
ظاهرا شما با فریم ورکها زیاد کار نکردید.داده های مدل به کنترلر داده میشن و سپس از کنترلر به ویو.تو فریم ورک ci یه جستجویی درباره آرایه $data تو کنترلر بکنید متوجه منظورم میشید:چشمک:برای نمونه یی هم به این روش


$model = new Users('create');

مدل رو فراخوانی میکنه.اگه جایی مشکلی بود بگید:لبخندساده:
اتفاقا CI زیاد کار کردم فریمورک های دیگه خیر...
تو اولین پروژه با CI اواسط پروژه بود که این مطلبو فهمیدم و چقدر هم کارم راحت شد...
تو همون مدل ویو رو فراخوانی میکردم اطلاعاتم میفرستادم فقط یه تابع فیلتر این وسط کار میکرد و نه هیچی دیگه اوایل پروژه اول اطلاعات از مدل میرفت به کنترلر بعد با اعمال هموون تابع میرفت به ویو
این قضیه که قرار نیست حتما اطلاعات از مدل بره به کنترلر رو که شنیدم اوایل پافشاری رو این که نه نمیشه و اینا میکردم چون یاد کرفتن این معماری سخت بود و بخوام چیزی که روش تسلط پیدا کردم رو تغییر بدم سخت ترش میکرد واسه همین پافشاری میکردم بعد که یواشکی انجامش دادم دیدم نه چقدر خوبه کدهام حدود 20% کمتر میشه چون اطلاعات موقع نمایش دیگه به کنترلر نیازی نداره...
و تو CI که من کار کردم هردو اینا که گفتم میشه بدون هیچ محدودیتی...

راستی واسه جواب دوستمون arash691ایشون گفتن واسه اعتبار سنجی سشن ها و تازه سشن مثال بود اعتبار سنجی هر چیزی نه تعریف سشن! بله تعریف سشن چون سشن خودش میتونه حتی یه جدول موقت باشه باید تو مدل ایجاد و مقدار دهی بشه ولی واسه اعتبار سنجی تو ویو اگه مثلا واسه فقط خوش آمد گویی هست میتونه انجام بشه...

Mohammadsgh
یک شنبه 04 آبان 1393, 23:29 عصر
آقا شما راست میگی:dشما از روش خودت برو ما هم از روش خودمون میریم:dاینجوری بهتره

H:Shojaei
دوشنبه 05 آبان 1393, 11:03 صبح
آقا شما راست میگی:dشما از روش خودت برو ما هم از روش خودمون میریم:dاینجوری بهتره
آقا شما راست میگی تو اینطور بحثا معنایی نداره...
روش منو شما هم نداره!
مهم بیس ام وی سی هست که هنوز معلوم نیست کدوم یکی واقعا بیس اصلیه!
من هم به روش شما ایراد نگرفتم و نگفتم شما بیاید از روش من برید شما خودتون باید به چیزی که درسته برسید کسی نمیتونه به شما بگه چی درسته چی غلط همونطور که من دارم تلاش میکنم به اون چیزی که تو این زمینه درسته برسم...

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

Veteran
دوشنبه 05 آبان 1393, 11:08 صبح
البته در نمایش اطلاعات به کاربر

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

H:Shojaei
دوشنبه 05 آبان 1393, 12:12 عصر
خب بحث اصلی اینجاس،شما اگر بیاید بدون کنترلر داده هارو بفرستید به سمت ویو و نمایش بدید مجبورید تماما کنترل داده هایی که میاد رو در ویو انجام بدید :متفکر:
از حلقه ها بگیر تا شرط ها،متغیر ها،اعمال توابع روی داده هایی که اومده و .... که بازهم ویو شلوغ میشه و بعدا دردسر میشه
بهتره بزارید هرکدوم کاره خودشون رو بکنند.مدل داده هارو بفرسته،کنترلر اعمال کنه و ویو نمایش بده
خوب شرطها...
اگه قراره شرط واسه یه کار کوچولو انجام بشه که چه بهتر تو همون ویو انجام بشه مثلا اعتبار سنجی ورود و نمایش پیام خوش گویی...

حلقه ها که باید تو ویو باشن وقتی یه درخواست به مدل فرستاده میشه که 10 رکورد رو میخواد و مقدار به کنترلر هم که فرستاده بشه کنترلر باید 10 رکورد رو به ویو بفرسته تا اونجا سطر ها تو یه حلقه نمایش داده بشه پس این کار با مدل هم میشه که همین ارسال با مدل صورت بگیره...

متغیر ها که اصن بحثی نداره که تو کنترل که تعریف بشن تو ویو هم میتونن در دسترس باشن حتی تو ویو هم اون چند متغیری که نیاز باشه که نشه کاریش کرد رو تعریف کنیم مشکلی پیش نمیاره...

اعمال توابع روی داده ها رو قبول دارم و از اول هم خودم اینو گفتم که مثلا یه تابع واسه فیلتر داده ها باید این وسط بین مدل و ویو (تو یکیشون فرق نداره) این کار رو انجام بده (حتی میشه طوری انجام این معماری پیاده بشه که وقتی اطلاعات از مدل به ویو ارسال میشه و قراره نمایش داده بشه خودکار این وسط با تابع ارسال اطلاعات این فیلتر هم اعمال بشه)...

Mohammadsgh
دوشنبه 05 آبان 1393, 21:49 عصر
حرفهای آقای
Veteran هم عین حرف منه.
مشکل شما اینه که هنوز mvc رو خوب درک نکردید.دارید میگید میشه تو ویو متغییر تعریف کرد.واین اشتباهه.بیشتر mvc کار کنید تا درکش کنید

hamedarian2009
دوشنبه 05 آبان 1393, 22:26 عصر
حرفهای آقای
Veteran هم عین حرف منه.
مشکل شما اینه که هنوز mvc رو خوب درک نکردید.دارید میگید میشه تو ویو متغییر تعریف کرد.واین اشتباهه.بیشتر mvc کار کنید تا درکش کنید

توی ویو هم میشه شرط ، حلقه و متغیر تعریف کرد و استفاده کرد

H:Shojaei
دوشنبه 05 آبان 1393, 22:43 عصر
حرفهای آقای
Veteran هم عین حرف منه.
مشکل شما اینه که هنوز mvc رو خوب درک نکردید.دارید میگید میشه تو ویو متغییر تعریف کرد.واین اشتباهه.بیشتر mvc کار کنید تا درکش کنید

بهتر نیست به جای اشتباه تلقی کردن اطلاعات دیگران حرفهای خودمون رو اثبات کنیم!:لبخندساده:

arash691
دوشنبه 05 آبان 1393, 23:05 عصر
حرفهای آقای
Veteran هم عین حرف منه.
مشکل شما اینه که هنوز mvc رو خوب درک نکردید.دارید میگید میشه تو ویو متغییر تعریف کرد.واین اشتباهه.بیشتر mvc کار کنید تا درکش کنید


پاسخ اقای شهرکی :

http://barnamenevis.org/showthread.php?443119-%D9%BE%DA%A9%DB%8C%D8%AC-%D8%A2%D9%85%D9%88%D8%B2%D8%B4-%D8%AA%D8%B5%D9%88%DB%8C%D8%B1%DB%8C-%D9%81%D8%A7%D8%B1%D8%B3%DB%8C-PHP&p=2124127#post2124127

Mohammadsgh
سه شنبه 06 آبان 1393, 17:27 عصر
دیدید آقای شهرکی هم همینو گفتن:لبخند:تعریف متغییر تو ویو درست نیست ولی میشه شرط و حلقه و اینا رو تو ویو تعریف کرد.اگه داده ها مستقیم از مدل به ویو فرستاده بشه دیگه کنترلر نقش زیادی بازی نمیکنه.این ساختار هم اصولی نمیشه.اگر هم احساس کردید تند صحبت کردم پوزش میخوام:لبخندساده:

hamedarian2009
سه شنبه 06 آبان 1393, 19:50 عصر
دیدید آقای شهرکی هم همینو گفتن:لبخند:تعریف متغییر تو ویو درست نیست ولی میشه شرط و حلقه و اینا رو تو ویو تعریف کرد.اگه داده ها مستقیم از مدل به ویو فرستاده بشه دیگه کنترلر نقش زیادی بازی نمیکنه.این ساختار هم اصولی نمیشه.اگر هم احساس کردید تند صحبت کردم پوزش میخوام:لبخندساده:
شما اگه به template engine سیمفونی که twig (http://twig.sensiolabs.org/doc/templates.html)هست نگاه کنید می بینید که انواع و اقسام شرط و حلقه و متغیر و دستور php و حتی فیلتر کردن داده ها رو میشه تو ویو سیمفونی استفاده کرد مثلا شما میخای زمان و تاریخ رو نشون بدی آیا لازمه بری کنترلر بعد مدل زمانو بگیری دوباره بیای کنترلر و بری تو ویو نشون بدی به نظرتون مستقیم تو ویو نشون بدی کم هزینه تر نیست؟

H:Shojaei
سه شنبه 06 آبان 1393, 21:35 عصر
دیدید آقای شهرکی هم همینو گفتن:لبخند:تعریف متغییر تو ویو درست نیست ولی میشه شرط و حلقه و اینا رو تو ویو تعریف کرد.اگه داده ها مستقیم از مدل به ویو فرستاده بشه دیگه کنترلر نقش زیادی بازی نمیکنه.این ساختار هم اصولی نمیشه.اگر هم احساس کردید تند صحبت کردم پوزش میخوام:لبخندساده:
فک نکنم آقای شهرکی این رو گفته باشنا یه نگاه دیگه بکنید به پستشون...
خوب شما میگید شرط و حلقه میشه ولی تعریف متغیر نمیشه!
مگه غیر از اینه که واسه اجرای یک حلقه باید حداقل از یه متغیر استفاده کرد !
وقتی بشه شرط و حلقه رو گذاشت دیگه سر تعریف متغیر چونه زدن معنایی نداره ;)
نه تند صحبت نکردید حرف من هم در جواب کاملا منطقی بود و اشاره به ناراحت شدن یا نشدنم نداشت ;)
در هر صورت من که جوابم رو از این تاپیک گرفتم شمام یه برانداز بکنید و هرطور صلاح میدونید عمل کنید ;)

Mohammadsgh
چهارشنبه 07 آبان 1393, 00:36 صبح
شما اگه به template engine سیمفونی که twig (http://twig.sensiolabs.org/doc/templates.html)هست نگاه کنید می بینید که انواع و اقسام شرط و حلقه و متغیر و دستور php و حتی فیلتر کردن داده ها رو میشه تو ویو سیمفونی استفاده کرد مثلا شما میخای زمان و تاریخ رو نشون بدی آیا لازمه بری کنترلر بعد مدل زمانو بگیری دوباره بیای کنترلر و بری تو ویو نشون بدی به نظرتون مستقیم تو ویو نشون بدی کم هزینه تر نیست؟
این یه چیز واضح و مشخصه.انگار منظور منو متوجه نشدید

Mohammadsgh
چهارشنبه 07 آبان 1393, 00:38 صبح
فک نکنم آقای شهرکی این رو گفته باشنا یه نگاه دیگه بکنید به پستشون...
خوب شما میگید شرط و حلقه میشه ولی تعریف متغیر نمیشه!
مگه غیر از اینه که واسه اجرای یک حلقه باید حداقل از یه متغیر استفاده کرد !
وقتی بشه شرط و حلقه رو گذاشت دیگه سر تعریف متغیر چونه زدن معنایی نداره ;)
نه تند صحبت نکردید حرف من هم در جواب کاملا منطقی بود و اشاره به ناراحت شدن یا نشدنم نداشت ;)
در هر صورت من که جوابم رو از این تاپیک گرفتم شمام یه برانداز بکنید و هرطور صلاح میدونید عمل کنید ;)
اینکه شرط متغییر و اینا تو ویو ایجاد شه زیاد گویای گفتگوی ما نیست.مهم گرفتن دادهاست که ویو نباید مستقیم از مدل بگیره

hamedarian2009
چهارشنبه 07 آبان 1393, 10:35 صبح
توی یک فایل پاورپوینت استاد شهرکی در مورد MVC توضیح دادن بخشیش اینجوری نوشته گفتم بد نیست اینجا بزارم
" برخی باورهای اشتباه درباره عنصر View به‌خصوص دربین توسعه‌دهندگان وب که از MVC استفاده می‌کنند، رایج است. برای مثال، بسیاری از آنها به‌اشتباه فکر می‌کنند که View هیچ‌گونه ارتباط مستقیمی با Model ندارد و تمام داده‌های موردنیاز جهت نمایش توسط View، ازطریق Controller ارسال می‌شود. درحقیقت، این روند با اصول MVC ناسازگاری کامل دارد اما متأسفانه این روند تا جایی رواج داشته‌است که در کتاب‌های آموزش MVC و حتی در برخی از فریمورک‌های معروف (مثل CakePHP) نیز از آن استفاده شده است. بعلاوه، توصیف View بعنوان یک فایل قالب نیز اشتباه است. هرچند، متأسفانه این باور نیز نه به‌صورت فردی بلکه دربین انبوهی از توسعه‌دهندگان و نویسندگان رایج است و منجر به یادگیری MVC به‌صورت اشتباه و در مرحله بعد، تدریس آن بصورت نادرست می‌شود. البته خوشبختانه در فریمورک‌های جدید و مدرن، این مسئله اصلاح شده‌است. بنابراین، همان‌طور که اشاره‌شد، داده‌های View ازطریق Controller تأمین نمی‌شوند و همان‌طور که قبلاً اشاره شد، هیچ‌گونه ارتباط مستقیمی بین View و Controller وجود ندارد و Model نقش پُل بین آنها را ایفا می‌کند."

Mohammadsgh
چهارشنبه 07 آبان 1393, 12:26 عصر
پس اگه اینطوره فریم ورک های yii-codeigniter-laravel ساختارشون اشتباه.چون یی و لاراول با متد render مدل رو فراخوانی میکنن.(برا لاراول متدشو مطمئن نیستم) و همینطور codeigniter که مدل رو تو کنترلر فراخوانی میکنه

MMSHFE
چهارشنبه 07 آبان 1393, 13:25 عصر
ببینید، هر دو روش امکان داره و وقتی هیچ کدوم از فریمورکهای معروف و مطرح جلوی ارتباط مستقیم ویو و مدل رو نگرفتن، یعنی اینکه ارتباطشون اشکالی نداره. البته اگه بعد از گرفتن اطلاعات، یکسری کارهای کنترلی خاص لازم باشه (مثلاً اگه رکورد موردنظر پیدا نشد، خطا بدیم یا کاربر رو به صفحه دیگری بفرستیم)، بهتره این کارها توی کنترلر انجام بشه. درهرصورت قلب MVC کنترلره اما معناش این نیست که ویو نمیتونه یکسری داده های ساده یا شرطهای کنترلری و حلقه و... رو خودش پیاده سازی کنه. قرار نیست کنترلرها هزاران خط کد بشن و ویوها فقط شامل HTML باشن! برای اینکه با مثال بگم، به دو تکه کد زیر دقت کنید که با Yii انجام شده:
حالت اول (نیازمند بررسی و کنترل و ارجاع به صفحه خطا درصورت یافت نشدن رکورد) :

public function actionView($id)
{
if(!($model = Products::model()->findByPk($id)) {
throw new CHttpException(404, 'Product not found.');
}
$this->render('view', array('model'=>$model));
}
حالت دوم (نیازمند بررسی و نمایش خطا در همان صفحه) :

public function actionIndex()
{
$this->render('index');
}
و حالا ویو index.php رو ببینید:

<?php $products = Products::model()->findAll('confirmed=1'); ?>
<?php if(!$products) : ?>
<p class="alert alert-danger">No products found.</p>
<?php else: ?>
<table class="table table-bordered table-condensed table-striped">
<tr class="info">
<th>ID</th>
<th>Name</th>
<th>Quantity</th>
</tr>
<?php foreach($products as $product) : ?>
<tr>
<td><?php echo CHtml::encode($product->id); ?></td>
<td><?php echo CHtml::encode($product->name); ?></td>
<td><?php echo CHtml::encode($product->quantity); ?></td>
</tr>
<?php endforeach; ?>
</table>
<?php endif; ?>
عمداً مثالها رو طوری انتخاب کردم که یکی نیاز به ارجاع به صفحه دیگه (صفحه خطا) داشته باشه و یکی دیگه مدیریت خطا رو خودش انجام بده. همونطور که میبینید، توی ویو داره خیلی کارها انجام میشه ولی واقعاً این کارها ربطی به کنترلر نداره چون میخوایم مدیریت خطا رو توی خود ویو انجام بدیم و همون صفحه است که اگه محصولی نداشته باشه، پیغام مناسب رو چاپ میکنه نه صفحه دیگه. پس لازم نیست اینجا کنترلر رو درگیر کنیم. خود ویو وصل میشه به مدل و داده ها رو میگیره و پردازش میکنه و فقط وظیفه کنترلر اینه که ورودی کاربر رو پردازش کنه و وقتی دید اکشن index صدا زده شده، ویوی لازم رو صدا بزنه. البته توی Yii میشه متغیرها رو بجای پاس دادن به ویو بصورت فیلد (با کمک this$) تعریف کرد و توی ویو هم با this$ بهشون دسترسی داشت. برای مثال، همون کد اول رو ببینید:

public function actionView($id)
{
if(!($this->model = Products::model()->findByPk($id)) {
throw new CHttpException(404, 'Product not found.');
}
$this->render('view');
}
حالا توی ویو view.php با this->model$ میتونیم به فیلد مربوطه از کنترلر دسترسی پیدا کنیم. بطور کلی تا وقتی که یکسری اعتبارسنجی و کنترل سطح بالاتر نیاز نیست، لزومی نداره کنترلر رو درگیر استخراج اطلاعات کنید چون وظیفه اش مشخصه: پردازش ورودیهای کاربر. اما اگه لازمه داده هایی که از دیتابیس گرفته میشه، قبل از اینکه تحویل ویو داده بشه، بررسی بشن و یکسری تصمیمات سطح بالاتر از ویو درموردشون گرفته بشه، اونوقت کنترلر مکان مناسبی برای استخراج اطلاعات خواهد بود. درغیر اینصورت استخراج اطلاعات در کنترلر و پاس دادن به ویو نه تنها لازم نیست، بلکه سربار هم میگذاره (یکبار توی کنترلر حافظه گرفته میشه و دوباره همون متغیر موقع ایجاد ویو براش کپی میشه و متغیر اصلی که داخل کنترلر ایجاد شده هم تا پایان نمایش ویو (و تکمیل اکشن کنترلر) در حافظه خواهد بود، درحالی که هیچ کاری باهاش ندارین و توی ویو دارین با کپی اون که داخل ویو تعریف شده کار میکنید.
این عکس هم ساختار داخلی MVC فریمورک Yii رو نشون میده:
http://www.yiiframework.com/tutorial/image?type=guide&version=1.1&lang=en&file=structure.png
منبع: http://www.yiiframework.com/doc/guide/1.1/en/basics.mvc

MMSHFE
چهارشنبه 07 آبان 1393, 13:42 عصر
به این عکس هم نگاه کنید:
http://www.yiiframework.com/tutorial/image?type=guide&version=1.1&lang=en&file=flow.png
این عکس هم از همون لینک برداشته شده و چرخه کار رو در فریمورک نشون میده. بعنوان یک چرخه استاندارد، بد نیست از این عکس استفاده کنیم تا یکسری ابهامها بطور کامل برطرف بشه:
1- کاربر چنین درخواستی میده: http://www.example.com/index.php?r=post/show&id=1 و وب سرور هم طبیعتاً index.php رو اجرا میکنه.
2- بوت استرپ (با Twitter Bootstrap اشتباه نگیرین) یک شئ از کلاس Application میسازه و اجراش میکنه.
3- شئ Application جزئیات درخواست کاربر رو از کامپوننت request میگیره (چیزهایی مثل مقادیر Get و Post شده و...)
4- شئ Application با کمک کامپوننت urlManager تشخیص میده که براساس مقادیر واردشده، کدوم اکشن از کدوم کنترلر مورد تقاضا بوده. برای مثال، توی url شماره 1 میفهمه که باید متد actionShow از کنترلر PostController رو اجرا کنه و مقدار id=1 رو که با Get ارسال شده رو بعنوان پارامتر بهش بده.
5- شئ Application یک شئ جدید از کنترلر PostController میسازه و بعد از اعمال فیلترهایی که داخلش تعریف شده (بررسی سطح دسترسی کاربر و...) درصورتی که کاربر مجاز به اجرای متد actionShow بود، متد رو صدا میزنه و پارامتر لازم (id$) رو تحویلش میده.
6- متد یک رکورد از جدول Post رو که id اون برابر با 1 بوده، با کمک مدل میخونه (این کار داره توی کنترلر انجام میشه).
7- متد ویو رو فراخوانی میکنه و مدلی که خونده بود رو تحویلش میده.
8- ویو فیلدها و مشخصه های مدل رو میخونه و نمایش میده.
9- ویو ممکنه برای نمایش اطلاعات، از یکسری ویجت استفاده کنه (مفهوم ویجت الان مهم نیست - توی مستندات فریمورک میتونید بخونید).
10- خروجی تولیدشده توسط ویو داخل Layout اصلی (مفهومی شبیه MasterPage) قرار میگیره.
11- متد کارش تموم شده و خروجی نهایی رو به کاربر نشون میده.

حالا یکبار دیگه به دقت به قسمتی از عکس که ارتباط مدل/ویو/کنترلر رو نشون میده دقت کنید. میبینید که ارتباط بین کنترلر و مدل دوطرفه است ولی بین مدل و ویو یکطرفه. این یعنی چی؟ یعنی اگه لازمه یکسری تغییرات توی رکوردها ایجاد بشه، وظیفه کنترلره که با کمک مدل اینکار رو انجام بده ولی اگه فقط خوندن موردنظر باشه، ویو هم میتونه به تنهایی اینکار رو انجام بده و مشکلی وجود نداره. پس هیچوقت توی ویوهاتون رکوردها رو تغییر ندین.

Mohammadsgh
چهارشنبه 07 آبان 1393, 14:38 عصر
اینکه شرط و حلقه و اینا میتونه تو ویو باشه 100% و منم همین کارو برای خوندن داده انجام میدم .گفتگوی اصلی ما پیوند مستقیم میان مدل و ویو هست.تو این 11 موردی که آقای شهرکی اشاره کردن هم روال به این صورته(البته برای فریم ورک یی) و روش انجام کار درسته.در یکسری کارهای خیلی خیلی خاص مدل مستقیم دادها رو به ویو میفرسته.درکارهایی مانند گرفتن داده از دیتابیس و اینجور چیزا که بالای 90% پروژه همچین کاریه باید کنترلر تو این کار نقش داشته باشه

MMSHFE
چهارشنبه 07 آبان 1393, 15:11 عصر
الان توی مثال دومی که گذاشتم، مستقیماً ویو داره با کمک مدل اطلاعات رو استخراج میکنه و این مسئله مشکل خاصی توی معماری MVC نداره. مسئله اینه که الان View برای استخراج اطلاعات از دیتابیس باز هم داره از مدل استفاده میکنه و تا وقتی که مستقیماً خود ویو بدون استفاده از مدل (فرضاً با کوئری زدن مستقیم) به دیتابیس وصل نشه، تضادی با مفهوم MVC نداره.