MVC vs 3-Tier Pattern
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: یک دقیقه

من تا به حال برنامه نویس‌های زیادی را دیده‌ام که می‌پرسند «چه تفاوتی بین الگوهای معماری MVC و Three-Tier وجود دارد؟» قصد من روشن کردن این سردرگمی، بوسیله مقایسه هردو، با کنار هم قرار دادن آنها می‌باشد. حداقل در این بخش، من اعتقاد دارم، منبع بیشتر این سردرگمی‌ها در این است که هر دو‌ی آنها، دارای سه لایه متمایز و گره، در دیاگرام مربوطه‌اشان هستند.

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


معماری سه لایه

سیستم‌های سه لایه، واقعاً لایه‌ها را می‌سازند: لایه UI به لایه Business logic دسترسی دارد و لایه Business logic به لایه Data دسترسی دارد. اما لایه UI دسترسی مستقیمی به لایه Data ندارد و باید از طریق لایه Business logic و روابط آنها عمل کند. بنابراین می‌توانید فکر کنید که هر لایه، بعنوان یک جزء، آزاد است؛ همراه با قوانین محکم طراحی دسترسی بین لایه ها.

MVC

در مقابل، اینPattern ، لایه‌های سیستم را نگهداری نمی‌کند. کنترلر به مدل و View (برای انتخاب یا ارسال مقادیر) دسترسی دارد. View نیز دسترسی دارد به مدل . دقیقاً چطور کار می‌کند؟ کنترلر در نهایت نقطه تصمیم گیری منطقی است. چه نوع منطقی؟ نوعاً، کنترلر، ساخت و تغییر مدل را در اکشن‌های مربوطه، کنترل خواهد کرد. کنترلر سپس تصمیم گیری می‌کند که برای منطق داخلیش، کدام View مناسب است. در آن نقطه، کنترلر مدل را به View   ارسال می‌کند. من در اینجا چون هدف بحث مورد دیگه‌ای می‌باشد، مختصر توضیح دادم.

چه موقع و چه طراحی را انتخاب کنم؟

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

  • #
    ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۰۳:۰۳
    3-Layer در واقع Architecture Style هست اما MVC یک Design Pattern هست پس مقایسه مستقیم نمیدونم کاری دست باشد یا نه اما میتونیم به این شکل نتیجه گیری کنیم:
    Data Access: شامل کلاسهای ADO.NET یا EF برای کار با دیتابیس.
    Business Logic: یا همان Domain logic که میتوان Model رو به عنوان  Business entity در این لایه بکار برد.
    UI Layer: بکارگیری Controller و View در این لایه

    • #
      ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۰۶:۰۳
      در برنامه نویسی 3لایه کار Business Logic به طور واضح و شفاف چی هست و چه کارهایی در این لایه لحاظ میشه ؟
      • #
        ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۱۳:۴۸
        لایه business Logic  در واقع لایه پیاده سازی Business پروژه شما می‌باشد با یک مثال عرض می‌کنم فرض کنید در لایه UI شما لازم دارید یک گزارش از لیست مشتریانی که بالاترین خرید را در 6 ماه گذشته داشته اند و لیست تراکنش مالی آنها را بدست آورید.برای این مورد شما توسط کلاسهای و متدهای لازم ، در لایه Business Logic  این عملیات را پیاده سازی می‌کنید.
      • #
        ‫۹ سال و ۷ ماه قبل، دوشنبه ۴ اسفند ۱۳۹۳، ساعت ۲۰:۴۶
        لایه کسب و کار مغز برنامه شما میباشد. یک زمانی میخواهید معادله ریاضی حل کنید در این لایه و زمانی نیز نیاز است مقداری داده از انباره داده خود بخوانید. لذا UI درخواست محاسبه معادله یا استخراج گزارش را به کسب و کار میدهد، کسب و کار بررسی میکند تا درخواست را پاسخ دهد. اگر برای پاسخ نیاز به انباره داده بود به لایه داده میفرستد تا مطابق با آن درخواست داده‌های مناسب استخراج شده و برگشت داده شوند.
        نکته ای که وجود دارد این است که لایه داده حتما نباید با یک پایگاه داده ارتباط برقرار کند، و لایه UI نیز نباید شخصا کار پردازشی یا منطقی انجام دهد و این کارها باید به لایه کسب و کار ارجاع داده شوند.
    • #
      ‫۷ سال و ۶ ماه قبل، شنبه ۲۸ اسفند ۱۳۹۵، ساعت ۱۶:۵۰
      درک من از معماری سه لایه یا N-Teir اینگونه است که
      اصولا باید تقسیم بندی لایه‌ها به این صورت باشه که:
      1-لایه زیرساخت که متشکل از DataLayer,ServiceLayer,domainclasses هست
      2-لایه وب سرویس که می‌تواند یک سرویس دهنده باشد مثل WebApi,Wcf
      3-لایه ui که هر نوع appی می‌تواند باشد .مانند Asp.Net Webforms,Asp.Net Mvc,Andriod ,Ios,Winphone و یا حتی php
      در واقع لایه وب سرویس هست که لایه ui رو تغذیه میکند.
      لایه ui با ارسال درخواست به لایه وب سرویس داده  مورد نظر خود را دریافت میکند و مهم نیست که این لایه از چه نوع تکنولوژی استفاده میکند.
      اینگونه است که میتوان وابستگی لایه‌ها را تفکیک کرد و به یک معماری مستقل رسید.
  • #
    ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۱۳:۱۱
    منم یه مدت دچار این ابهام بودم. ولی الان اینطور نتیجه می‌گیرم:

    mvc کلا در لایه UI قرار داره. یعنی اگر شما لایه BL و DAL رو داشته باشید، حالا میتونید لایه UI رو با یکی از روش ها، مثلا سیلورلایت، asp.net mvc یا asp.net web form پیاده کنید. 
    • #
      ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۱۳:۱۹
      همون لایه UI هم نیاز به جداسازی کدهای نمایشی از کدهای مدیریت کننده آن برای بالابردن امکان آزمایش کردن و یا حتی استفاده مجدد قسمت‌های مختلف اون داره. در این حالت شما راحت نمی‌تونید MVC و Web forms رو در یک سطح قرار بدی (که اگر اینطور بود اصلا نیازی به MVC نبود؛ نیازی به MVVM برای سیلورلایت یا WPF نبود و یا نیازی به MVP برای WinForms یا Web forms نبود).
      • #
        ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۱۳:۴۳
        دوست عزیز من متوجه منظور شما نشدم. حرف من اینه که MVC، MVVM، MVP و .. در سطح UI پیاده میشن.
        • #
          ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۱۴:۰۸
          این طور نیست دوست عزیز شما می‌تونید حتی برای Model هم لایه در نظر بگیرید که براحتی توسط لایه Business و کلا لایه‌های دیگر در دسترس باشد.که این مورد الان در MVC خیلی کاربرد دارد.مواردی که من عرض کردم برای رفع ابهام بین معماری چند لایه و Pattern MVC بود.
    • #
      ‫۹ سال و ۳ ماه قبل، جمعه ۵ تیر ۱۳۹۴، ساعت ۲۳:۰۲
      به نظر من این درست نیست که بگیم mvc کلا در لایه UI می‌باشد، ببینید شما وقتی می‌خواهید یک application را توسعه بدید علاوه بر اهداف بیزینسی application که قصد توسعه ان را دارید یکسری اهداف تکنولوژیکی هم مد نظر دارید، حالا بعضی از این اهداف می‌تواند بسیار پایه ای باشد مانند اینکه شما این application  را بصورت win app , web app یا mobile app یا ترکیبی پیاده سازی کنید، وبعضی تصمیمات هم بعد از این تصمیم گیری انجام میشوند، برای مثال شما در نظر می‌گیرید که می‌خواهید این application را به صورت یک web app پیاده سازی کنید، حال شما ممکن است به عنوان طراح نرم افزار یا یک معمار یکسری concern ریز و درشت دیگر برایتان ایجاد شود، باز هم برای مثال: این application باید SOC را در تمامی سطوح درنظر بگیرد و decoupling به یک سطح مناسب برساند، ویا اینکه هدف این که لایه business را طوری طراحی کنیم که به یک repository خاص یا یک ui framework وابسته نباشد، اما هدف من از این همه اسمان ریسمان‌ها این بود که بگم که مثلا نمی‌توان گفت که فلان تکنولوژی باید در فلان موقعیت و به فلان روش استفاده شود بلکه این شما هستید که بر حسب concern‌های خود چگونه تصمیم بگیرید.
  • #
    ‫۱۱ سال و ۴ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۲۱:۴۴
    به بنظر بنده هم معماری رو نمی‌شود با الگو مقایسه کرد به هر حال خود الگوی mvc‌ها یک سری لایه داره و تا اونجایی هم که می‌دونم فرق tier با layer اینه که tier‌ها رو از لحاظ فیزیکی هم جدا می‌کنند
  • #
    ‫۷ سال و ۶ ماه قبل، چهارشنبه ۲۵ اسفند ۱۳۹۵، ساعت ۱۸:۵۶
    با سلام؛ آیا میشه منطق بیزینس لایر رو تو خود مدل پیاده سازی کرد؟ یا مثلا منطق Data access layer رو تو خود Model رو بتونیم پیاده سازی کنیم؟ به عبارتی مثلا قسمت Model برنامه از یه ساختار درختی دیگه ایی برخوردار باشه یعنی یه جورایی N tier رو بتونیم تو هر یک از این بخش‌ها پیاده سازی کنیم ... مثلا وقتی جداول ما تو پوشه مدل ساخته میشه بتونیم method‌ها و اون بیزینس لایر رو هم تو همین پوشه براش در نظر بگیریم؟ 
    و سوال دوم این که وقتی ما طبق این شکل آخر تو پوشه UI داریم از مدل استفاده می‌کنیم و کلاس‌ها رو قرار میدیم تو این قسمت پس اون قسمت Data access layer رو برای چی در نظر گرفتیم ؟ آیا میشه گفت که در پوشه مدل کلاس هایی هستند که در واقع بعضی از پارامتر‌های ارسالی رو برای View در این قسمت از کلاس Data access layer در نظر گرفتیم و این یه زیر مجموعه ایی از این قسمت حساب میشه ؟
    • #
      ‫۷ سال و ۶ ماه قبل، چهارشنبه ۲۵ اسفند ۱۳۹۵، ساعت ۲۲:۳۱
      - الگویی هست به نام active record که چنین طراحی داره.
      - در MVC اون مدل ViewModel هست در اصل.
      • #
        ‫۷ سال و ۶ ماه قبل، شنبه ۲۸ اسفند ۱۳۹۵، ساعت ۰۵:۵۸
        این الگوی Active record در واقع میاد مثلا تو یه 3 Tier به صورت درختی داخل هر بخش , بخش‌ها رو از هم مجزا می‌کنه مثلا تو بخش Data access layer اگه من خوام اطلاعات فیلد‌ها رو نگه دارم به صورت جدا و پیاده سازی‌های متد هایی رو هم که برای کار با دیتابیس نیاز هست اونا رو هم تو یه Folder مجزا قرار بدم در واقع دارم از این الگو استفاده می‌کنم  ... چون توضیحاتش رو خوب متوجه نشدم از این جهت پرسیدم
        • #
          ‫۷ سال و ۶ ماه قبل، شنبه ۲۸ اسفند ۱۳۹۵، ساعت ۱۴:۴۷
          الگوهای زیادی برای طراحی نرم افزار وجود دارند. اما در چارچوب MVC و EF، الگوی unit of work و تزریق وابستگی‌های سرویس‌های برنامه بیشتر مرسوم هستند. الگوی active record بیشتر در ruby استفاده می‌شود. اگر علاقمندید که در مورد الگوهای یاد شده بیشتر مطالعه کنید، قسمت لایه بندی مسیر راه EF را مطالعه کنید. یک سری پروژه‌ی خوب هم در قسمت پروژه‌های سایت  مثل decision و فروشگاه iris این الگوها رو پیاده سازی کردن که برای مطالعه فوق العاده مفید هستند.