تهیه پیش‌فروش دوره «آموزش تکمیلی و پروژه محور Spring Boot» با ۳۵% تخفیف - فقط تا ۱۳ شهریور 

معماری MVP و MVC در اندروید - قسمت اول

یکشنبه ۱۶ اردیبهشت ۹۷ توسط فاطمه بهاروند

MVP and MVC

این مقاله اولین نسخه از مجموعه مقالات درباره ی MVC) Model View Controller) و MVP) Model View Presenter) در زمینه ی توسعه ی اندروید است.

چرا شما باید به MVP و  MVC علاقمند باشید؟

بیانیه ی رابرت مارتین "عمو باب" را ملاحظه کنید:

تنها راه رسیدن به انتهای کار(به عبارت دیگر تنها راه پیمودن سریع مسیر انجام کار) این است که در هر لحظه کد خود را تا حد امکان واضح و تمیز نگهداری کنیم.

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

پیاده سازی صحیح MVP و MVC دارای ویژگی های زیر است:

  • کدهای خوانا و قابل نگهداری
  • کدهای ماژولار که سطح بالایی از جداسازی را فراهم می آورند
  • کدهای قابل تست بیشتر
  • کدهایی که برنامه نویسان از کار با آن لذت ببرند

خصوصیات ذکر شده به طور کلی با "کد تمیز" مشترک است. بنابراین با توجه به استدلال عمو باب سازگاری با MVP یا MVC به ما اجازه می دهد تا کار خود را سریعتر پیش ببریم.

تاریخچه و اعتبارات:

توسعه ی اندرویدی با آشفتگی خو گرفته است.

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

 مطمئنا این رویکرد منجر به رشد مداوم کلاس ها و تولید هزاران خط کد در طراحی ها می شد.

به تدریج اعضای جامعه اندروید که در این پلتفرم تجربه کسب کرده بودند روش های بهتری برای نوشتن برنامه ها ارائه کردند. ایده ی جداسازی منطق UI از بقیه ی برنامه مطرح شد، اما زمان زیادی طول کشید تا در جامعه ی توسعه دهندگان نفوذ کرده و گسترش یابد.

قدیمی ترین مقاله ای که در مورد ارائه ی لایه های معماری در اندروید توانستیم بیابیم به نوامبر 2010 بر می گردد. این مقاله با عنوان Android Architecture:Message-based MVC است که توسط ایوان ممرک(Ivan Memruk) در وبلاگ شخصی ایشان با نام Mind The Robot منتشر شده است.

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

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

در نوامبر 2011 جاش ماسل وایت(Josh Musselwhite) مجموعه ای 9 مقاله با عنوان معماری اندروید منتشر می کند. در این مجموعه جاش ایده های ایوان را بسط داده و به برخی جزئیات پیاده سازی می پردازد.

این می توانست پایان داستان باشد اما خوشبختانه اینگونه نبود.

در ژانویه ی 2012 جاش 10 مقاله را در مجموعه ای تحت عنوان بررسی دوباره ی Activity ارائه می دهد. در این پست ها جاش با بیان این دیدگاه که Activity در MVC یک View نیست اما یک کنترل کننده است در توسعه ی اندروید انقلابی به وجود آورد.

من مقالات ایوان و جاش را در سال 2014 خواندم و با تلاش یک الگوی معماری عالی برای لایه ی Presentation در اندروید ارائه کردم که بلافاصله به فروش رسید. از آن زمان به بعد ایده های خود را بیش از پیش گسترش دادم و خلاصه آنچه را که آموخته ام در چندین مقاله از خود ارائه دادم.

در مقاله Activityها در اندروید عناصر UI محسوب نمی شوند توضیح داده شده است که چرا آن ها حاوی منطق UI نبوده و به طور طبیعی باید در نقش کنترل کننده ها قرار گیرند.

این مجموعه مقالات چگونگی پیاده سازی الگوی معماری MVC را در اندروید نشان می دهد.

توسعه یافته ترین الگوی معماری برای پیاده سازی اندروید:

در بخش قبل چگونگی یادگیری خود را برای شما بازگو کردم و قصد دارم اطلاعات خود را در این مقاله و مقالاتی که در آینده منتشر می شود با شما به اشتراک بگذارم.

قبل از آنکه بر بحث طراحی نرم افزار تمرکز کنیم، می خواهم این نکته را در نظر داشته باشید که الگوی معماری توسعه یافته ای که امروزی از سال 2010 توسط دست کم 3 متخصص مستقل توسعه یافته و کامل شده است.

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

طرح کلی

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

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

قسمت سوم نیز به بخش Controller/Presenter را اختصاص یافته است.

 مفاهیم و تکنیک های اصلی با برنامه های آموزشی متن باز به صورت کاملا کاربردی ارائه خواهد شد. این برنامه تنها برای نمایش توانایی پیاده سازی MVP/MVC تمیز نوشته شده است.

همچنین برنامه ی کاربردی متن باز در دنیای حقیقی وجود دارد که از رویکردهای توصیف شده در این مجموعه مقالات استفاده می کند. کد این برنامه می تواند به عنوان مرجع برای موارد پیشرفته تر از آنچه در برنامه آموزشی ارائه شده است به کار گرفته شود(مانند راهنمای کشویی یا Navigation Drawer).

Model؟ View؟ Controller؟ Presenter؟

MVP و MVC الگوهای معماری هستند. ایده ی الگوها این است که بسیاری از سیستم های نرم افزاری که دارای رابط کاربری هستند می توانند به سه بخش تقسیم شوند:

  • مولفه ای که ورودی/خروجی سیستم را ذخیره می کند(چه این حالت ماندگار باشد و چه نباشد). این مولفه با عنوان Model شناخته می شود.

  • مولفه ای که ورودی/خروجی هایی که به کاربر نمایش داده می شود و یا از کاربر دریافت می شود را مدیریت می کند و به عنوان View خوانده می شود.

  • مولفه ای که عملکردهای منطقی سیستم را محاسبه می کند این جزء نیز به عنوان Controller/Presenter شناخته می شود.

اجزای یک پیاده سازی خوب MVP/MVC باید تا حد امکان از هم جدا باشند: جا به جایی از یک نهاد مستقل ورودی/خروجی (View) به مورد دیگر امکان پذیر باشد، تغییر موقعیت یا تغییر نوع مکانیزم ذخیره سازی (Model) بدون اثربخشی بر اجزای دیگر باید میسر باشد.

تفاوت MVC و MVP در چیست؟

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

اگر کنجکاوید بدانید که تعاریف MVC و MVP در نظر افراد مختلف تا چه اندازه متفاوت است، این موضوع را در StackOverflow بخوانید.

افراد علاقمند می توانند این مقاله ارزشمند درک گریر(Derek Greer) را نیز مطالعه کنند، ما خود تعریف کاملی از MVC داریم اما دیدگاه ما در مورد MVP با "الگوی View انفعالی" درک مطابقت خواهد داشت.

حال بیایید دیاگرام های تعامل MVC و MVP را کنار هم بگذاریم و آنها را مقایسه کنیم:

MVC_MVP

اکنون می توانید شباهت زیاد این الگوهای معماری را ببینید. تفاوت های کلیدی آن ها بدین شرح است:

  1. در View ،MVC از هرگونه تغییر در حالت Model توسط خود Model آگاه می شود، در View ،MVP هیچ اطلاعی از Model ندارد و این وظیفه Presenter است که داده های به روزرسانی شده را از Model واکشی کند، همچنین متوجه شود که View باید به روزرسانی شده و داده های جدید به آن متصل شوند.

  2. Viewها در MVC تمایل دارند منطق بیشتری در خود داشته باشند چرا که مسئولیت رسیدگی به اعلانات از Model بر عهده ی آن ها است. در MVP منطقی مشابه در Presenter قرار گرفته است که سبب خاموشی و سکون(به این معنا که کار خاصی انجام نمی دهد) View می شود. تنها هدف آن ثبت ورودی های گرفته شده از کاربر و همچنین پرداختن به داده هایی است که توسط Presenter به آن محول شده است.

در MVC این bottom line است که View را از وجود Model آگاه می سازد و آن ها به طور مستقیم با هم ارتباط برقرار می کنند در صورتی که در View ،MVP و Model هیچ اطلاعی از یکدیگر ندارند.

اندروید کدام یک از الگوهای معماری MVC/MVP را پشتیبانی می کند؟

سوال این نیست که الگوی معماری توصیه شده توسط گوگل برای توسعه ی برنامه های اندروید کدام یک از الگوهای MVC/MVP است(در حال حاضر تا سال 2016 مورد خاصی از بین این دو برگزیده نشده است و گوگل تغییراتی در هر دو الگوی معماری اعمال کرده و آنان را ارتقا داده است)، بلکه سوال این است که آیا در اندروید موردی هست که مانع توسعه دهندگان از اتخاذ این الگوی معماری شود؟

بخش "M" خوب است، تکمیل عملکرد مستقل Model در اندروید آسان است. به طور کلی زمانی که شما با آن خو بگیرید این ContentProvider است که از طریق ContentResolver یک MVC ،Model خیلی خوب می سازد، مستقل از رویکرد بقیه ی کد است که مکانیزم ذخیره سازی اصلی را کاملا خلاصه می کند.

اگر ContentProvider برای نیازهای برنامه بیش از حد پیچیده یا محدود است، یک Model خوب نیز می تواند با استفاده از کتابخانه های موجود(مانند کتابخانه ی ORM) یا با استفاده از حافظه ی پنهان سفارشی(memory cache) آن را اجرا نماید.

تلاش برای جداسازی View از قابلیت Controller مشکل ساز است، برای مثال قطعه کد زیر از سایت توسعه دهندگان اندروید کپی شده است:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // Set the user interface layout for this Activity
    // The layout file is defined in the project res/layout/main_activity.xml file
    setContentView(R.layout.main_activity);

    // Initialize member TextView so we can manipulate it later
    mTextView = (TextView) findViewById(R.id.text_message);

    // Make sure we're running on Honeycomb or higher to use ActionBar APIs
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        // For the main activity, make sure the app icon in the action bar
        // does not behave as a button
        ActionBar actionBar = getActionBar();
        actionBar.setHomeButtonEnabled(false);
    }
}

بگذارید برای چند لحظه فراموش کنیم که این قطعه کد ناچیز و ساده است و آن را از دیدگاه View و Controller/Presenter تجزیه و تحلیل کنیم:

  • ()OnCreate یک متد lifecycle است که توسط چارچوب اندروید برای پاسخ به تغییر حالت داخلی آن فراخوانی شده است. این تغییرات ممکن است مربوط به اعمال کاربر در برنامه باشد و حتی امکان دارد به این تغییرات ارتباطی نداشته باشد، به هر حال برنامه هرگز به طور مستقیم ()OnCreate را فراخوانی نمی کند.

    ممکن است تصور کنید این متد متعلق به View و قسمتی از MVC است چرا که در ادامه ()setContentView یک اتصال استاندارد از View است که توسط Controller/Presenter اجرا شده است.

    علاوه بر این ()OnCreate (یا دیگر متدهای lifecycle) وظیفه ی مراقبت از راه اندازی و اتصال Modelها، تخصیص منابع و مدیریت وضعیت برنامه را نیز برعهده دارند. تمام این امور را Controller/Presenter انجام می دهند.

  • Activity مدیریت UI برنامه را نیز برعهده دارد. در قطعه کد ذکر شده فقط دو عنصر مرجع (R.layout.main_activity و R.id.text_message) برای عناصر UI وجود دارد، با این حال این روش برای توصیف تمام قابلیت های مربوط به UI در Activity گسترش یافته است.

نتیجه ی آن این است که به طور پیش فرض Activityها مسئولیت های View و Controller/Presenter را بر عهده دارند. اگر بخواهیم الگوهای معماری MVC و MVP را اجرا کنیم، انجام جداسازی دستی آن بر عهده ی ما است.

نقش Activity:

Activity به طور پیش فرض هر دو مورد View و Controller/Presenter را در خود دارد، باتوجه به نحوه پیاده سازی MVC و MVP ما باید انتخاب کنیم کدام یک از مسئولیت ها را از آن استخراج کنیم.

مسئله ی انتخاب بین دو الگو بی اهمیت نیست ولی در جامعه ی اندروید هیچ توافقی وجود ندارد که کدام رویکرد بهتر است.

بسیاری از پیاده سازی های جایگزین الگوهای MVP/MVC که شما می توانید در اینترنت بیابید Activity را به عنوان View برمی گزینند و Controller/Presenter را از آن خارج می کنند. من گمان نمی کنم این رویکرد بهینه باشد و ترجیح می دهم Activity را به عنوان Controller/Presenter مطرح نموده و عاملیت View را از آن استخراج کنم. توجیه رفتار Activity به عنوان Controller/Presenter در این مقاله ارائه شده است: Activity در اندروید از جمله عناصر UI نیست.

کدام یک از الگوهای معماری برای توسعه ی اندروید مناسب تر است - MVC یا MVP؟

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

به نظر من MVP برای اندروید مناسب تر است زیرا برای توسعه ی اجزای View و Model ساده تر و تمیز تر است.

اگر ما به View و Model اجازه دهیم که به طور مستقیم با یکدیگر در ارتباط باشند. ممکن است در موقعیتی قرار بگیریم که View نیاز به آگاهی از رویداد lifecycle داشته باشد. از آنجایی که این رویدادها به طور مستقیم به مدیریت UI وابسته هستند، آگاه ساختن View از آن ها باعث مختل شدن و درهم ریختگی و انتزاع UI برنامه می شود.

همچنین به دلیل اینکه انتزاع کامل UI برای دستیابی به "کد تمیز" بسیار مهم است، من برای توسعه ی اندروید MVP را ارجح بر MVC می دانم.

نتیجه گیری:

در این مقاله ما الگوهای معماری MVP و MVC را به طور کلی بررسی کردیم و همچنین در مورد کاربرد آن ها در زمینه ی توسعه ی اندروید بحث نمودیم.

مقاله ی بعدی(قسمت 2) چگونگی منطق مدیریت UI انتزاعی را در مولفه ی View شرح می دهد.


کلیدواژه: اندروید MVP MVC Android معماری MVP در اندروید معماری MVC‌ در اندروید

منابع: www.techyourchance.com

دیدگاه ها:
حسین
۱ سال قبل
reply
یه مقاله عالی و بدون نقص
خیلی خوب بود، ممنون

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