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

مقدمه

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

اهداف

شما می خواهید حجم زیادی از کد را با اتوماسیون انجام دهید. (View ها واقعا سخت تست می شوند)

شما می توانید منطق برنامه را از view جدا کنید که باعث می شود نگهداری کد ساده تر شود.

راه حل

جدا کردن کد منطقی برای مدیریت رفتار در صفحه به وسیله قرار دادن آن ها در دو کلاس است و این دو کلاس View و Presenter نام گذاری شده اند. View یا همان صفحه ای که به کاربر نمایش داده می شود صفحه وب و رفتار کاربر را کنترل می کند و این رفتار ها را به presenter منتقل می کند. Presenter در واقع شامل منطق برنامه می شود که به رفتار ها، رویداد ها و به روز رسانی های مدل پاسخ می دهد (هم به منطق برنامه و هم به داده برنامه)، و همچنین وضعیت نمایش در view را نیز کنترل می کند.

برای اینکه بتوانید presenter را تست کنید، یک رابط کاربری تعریف کنید و به presenter اجازه دهید تا به view دسترسی داشته باشد به جای اینکه کلاس های View را بسازید. این کار به شما اجازه می دهد تا یک unit test را در view اجرا کنید.

در اینجا چند مدل مختلف از الگوی MVP وجود دارد. در برنامه های partner portal از supervising presenter استفاده می شود. (البته نام دیگر آن Supervising controller است). در Supervising presenter، بخش View مستقیما با model در ارتباط است برای انجام اعمال ساده مقید سازی داده data binding که می تواند مستقیما تعریف شود، بدون دخالت presenter در کار آن ها. Presenter می تواند model را به روز رسانی کند. فقط حالت View را زمانی که کد منطقی پیچیده ای داشته باشد، تغییر می دهد. به عنوان مثال کد منطقی UI پیچیده می تواند شامل تغییر رنگ کنترل، پنهان سازی پویا یا نمایش کنترل ها باشد. برنامه های Partner Portal مثال های زیادی از MVP دارد که می توانید از الگوی Supervising Presenter پیروی کنید.

دیاگرام زیر نشان می دهد عملکرد الگوی MVP را نمایش می دهد.

در مقایسه با نسخه های مختلف MVP، مانند Passive View، Supervising Presenter که باعث می شود ساده تر کد بزنید و اولویت بالاتری در تست نیز دارند. الگوی Supervising Presenter نیاز دارد تا کد کمتری بزند تا الگوی های MVP به این دلیل که از مقید سازی داده ها نیز استفاده می کند. کد می تواند راحت تر نگهداری شود به این خاطر که UI ساده تغییر می کند و دیگر نیازی به تغییر کد در presenter نیست.

جزئیات پیاده سازی

در یک برنامه معمولا مدل در یک جایی از domain business logic قرار می گیرد. شما می توانید فرض کنید این هدف مثال زیر را در بر می گیرد.

اولین گام این است که الگو MVP یک View را می سازد. به طور معمول، شما می خواهید یک مثالی بسازید از یک interface view که بخشی از محصولات را نمایش می دهد.

C#
    public interface IRelatedPartsView
    {
        IEnumerable<Part> Parts { get; set; }
        void DataBind();
        string ErrorMessage { get; set; }

    }

View پیاده سازی شده توسط User Control، کد زیر را شامل می شود.

C#
public partial class RelatedPartsControl : System.Web.UI.UserControl , IRelatedPartsView
    {
        private RelatedPartsPresenter presenter;

        public RelatedPartsControl()
        {
            presenter = new RelatedPartsPresenter(this);
        }

        // ...

        public IEnumerable<Part> Parts
        {
            get
            {
                return this.PartsRepeater as IEnumerable<Part>;
            }
            set
            {
                this.PartsRepeater.DataSource = value;
            }
        }

        // ...
        
        public string ErrorMessage { get; set; }

        protected void LoadPartsButton_Click(object sender, EventArgs e)
        {
            this.presenter.LoadParts(this.Sku);
        }
    }

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

برنامه Partner Portal و MVP

برنامه Partner Portal در الگو برنامه نویسی MVP به دو نوع مختلف از supervising presenter اشاره می کند. در یک نوع، یک user control شامل یک بخش وب است. آن user control بخش View را پیاده سازی می کند. View سازنده presenter بصورت داخلی است و متد های داخل presenter را صدا می زند.به این معنا است که presenter از بخش نمایش به کاربر مخفی است. مزیت اینکار سادگی آن است، به همین دلیل بخش view نیازی ندارد که هیچ اطلاعاتی از controller داشته باشد. عیب این کار این است که هر داده ای که بخواهد از بخشی از وب ارسال شود، باید به ابتدا به presenter برود.

کلاس PartnerRollupWebPart نشان دهنده نوع دیگری از supervising presenter است. در اینجا بخشی از وب شامل یک user control است که view را پیاده سازی می کند  و مستقیما با presenter در ارتباط است.

سازنده کلاس PartnerRollupWebPart، view را می سازد و نشان view را به سازنده presenter عبور می دهد.

دیاگرام زیر نشان دهنده دو Supervising presenter است. خط های ثابت، نشان دهنده جایی هستند که بخش وبی یا همان web part تعامل مستقیم با presenter ندارد. خطوط نقطه چین نشان دهنده جایی است که مستقیم با presenter ارتباط دارد.

به صورت معمول، user control ها پایه توسعه وب هستند در زمان طراح، این به این معنی است که منطق view بیشتر شبیه به موارد استفاده شده در user control است. جایی که web part شامل یک کد پیاده سازی view با user control نباشد، web part یک view interface  و مستقیما presenter را فعال می کند.

Presenter تنها تعامل دارد با view interface. این حالت presenter را از view جدا می سازد. زمانی view به presenter عبور داده می شود که presenter ساخته شده باشد. این رویکرد گاهی وقت ها اشاره می کند به contructor injection. به همین دلیل view عبور داده می شود به presenter، که شما می توانید برای view یک unit test بنویسید. کد زیر نشان دهنده constructor injection است:

C#
public class RelatedPartsPresenter
{
  IRelatedPartsView view;

  public RelatedPartsPresenter(IRelatedPartsView view)
  {
     this.view = view;
  }
        
  public void LoadParts(string sku)
  {
     try
     {
        IProductCatalogRepository productCatalogRepository =
           SharePointServiceLocator.Current.GetInstance<IProductCatalogRepository>();

        IEnumerable<Part> parts = productCatalogRepository.GetPartsByProductSku(sku);
        if (parts != null && parts.Any())
        {
           view.Parts = parts;
        }
        else
        {
           view.ErrorMessage = Resources.NoPartsFoundError;
        }
        view.DataBind();
     }
    // ...
  }
}

Presenter بخش model را دریافت و نمایش می دهد از بخش جدول محصول در مخزن (repository). presenter درواقع بخش مدل را در view نمایش می دهد، که به این اتفاق عمل data binding می گویند. مکان یاب سرویس قابلیت تست پذیری برنامه را نیز افزایش می دهد.

ملاحظات

در اینجا چند موضوع وجود دارد که باید ملاحظه کنید اگر می خواهید از الگو MVP استفاده کنید:

چند راه حل برای مدیریت عناصر وجود دارد

شما باید یک روش را برای ساختن یک راه ارتباطی میان view و presenter را انتخاب نمایید.

مدل از وجود presenter آگاه نیست. اگر تغییری در مدل به وسیله هر کامپوننتی انجام شود، باید حتما presenter از آن با خبر باشد. بصورت معمول، اطلاع رسانی به وسیله event ها به وجود می آید. این یک سناریو رایج در برنامه های وب نیست.

الگو MVP در برنامه های Parner Portal و Training management بصورت درجه اول برای unit testing است. یک مزیت بهتر توانایی جدا سازی منطق از دیگر لایه ها است. برنامه تطبیق داده شده با MVP و repository pattern با یک تکنیک توسعه نرم افزار به نام unit testing با mock objects مواجه می شوند. این تکنیک تست، وابستگی ها را بر روی کامپوننت های خارجی، مانند sharepoint می شکند.

آموزش سی شارپ