معماری سه لایه در مهندسی نرم افزار چیست؟ | راهنمای جامع

محور اصلی این نوشته، معماری سه لایه است اما، پیش از پرداختن به آن، ابتدا به شرح و تعریف معماری چند لایه (N-Tier) پرداخته شده است.

معماری چند لایه چیست ؟
یک برنامه کاربردی یا اپلیکیشن چند لایه (N-Tier Application) برنامهای است که میان سه یا بیش از سه رایانه مجزا در یک شبکه توزیعی پخش شده باشد. واژه Tier به معنای رده، طبقه یا سطح است. اگرچه بیشتر از اصطلاح «لایه» (Layer) به جای «رده» (Tier) استفاده میشود.
رایجترین شکل اپلیکیشن یا معماری چند لایه، معماری سه لایه است که به سه مقوله طبقهبندی میشود:
- برنامهنویسی رابط کاربری (User Interface) در رایانه کاربر
- منطق کسبوکار (Business Logic) در یک رایانه متمرکز
- دادههای مورد نیاز در یک کامپیوتر که یک پایگاهداده را مدیریت میکنند.
مدل معماری چند لایه و خصوصاً مدل معماری سه لایه، برای توسعهدهندگان نرمافزار، امکان ساخت و ایجاد اپلیکیشنها یا سامانههایی با انعطافپذیری بیشینه را فراهم میسازد. در معماری چند لایه N-tier، حرف N به تعداد سطوح یا لایههای استفاده شده در آن مدل اشاره دارد. به عنوان مثال، 2-tierبه معنی معماری دو لایه است. همچنین به مدل معماری چند لایه، Multi-Tier Architecture نیز گفته میشود.
تفاوت لایه و رده چیست ؟
در مباحث معماری سه لایه (3-Tier)، اغلب از واژه لایه (Layer) اشتباهاً به جای واژه رده (Tier) استفاده میشود. مثلاً به ردههای این معماری، «لایه نمایش» (Presentation Layer) یا «لایه منطق کسبوکار» (Business Layer) گفته میشود. این دو واژه یکسان نیستند. یک «لایه» به تقسیمبندی عملکردی یک نرمافزار اطلاق میشود اما، یک «رده» به تقسیمبندی عملکردی نرمافزار اجرا شده روی زیرساختهای مجزا از سایر بخشها اطلاق میشود.
معماری چند لایه
نمایش نموداری از یک سامانه چند لایه به صورت زیر است:
- نمایش (Presentation)
- کاربرد (Application)
- پایگاهداده (Database)

این سه لایه را میتوان بسته به نیاز، به زیر لایههای بیشتری تقسیمبندی کرد. در ادامه، برخی از وبسایتهایی که این معماری را به کار بردهاند فهرست شده است:
- MakeMyTrip.com
- کاربردهای سازمانی Sales Force
- راه آهن هند - IRCTC
- سایت آمازون
اصطلاحات رایج در خصوص معماری چند لایه
شبکه توزیع شده
مثالی از یک شبکه توزیعی
معماری کلاینت سرور
مثالی از مدل کلاینت سرور: دستگاه خودپرداز
پلتفرم
مثالی از یک پلتفرم
پایگاه داده
نمونهای از پایگاهداده
منطق کسب و کار
نمونهای از منطق کسبوکار
برای مثال، منطق کسبوکار نحوه محاسبه کل مالیات از اقلام فاکتور را تعیین می کند.
انواع معماری چند لایه
انواع مختلفی از معماری چند لایه وجود دارد. از جمله انواع معماری چند لایه میتوان به معماری سه لایه و معماری دو لایه یا معماری تک لایه اشاره کرد. در این مطلب، تمرکز اصلی روی معماری سه لایه است که در ادامه به آن پرداخته میشود.
معماری سه لایه به چه معنا است ؟

معماری سه لایه چیست ؟
معماری سه لایه یک معماری کاربرد نرمافزاری است که برنامههای کاربردی را در سه لایه محاسباتی منطقی و فیزیکی سازمان میدهد. این سه لایه شامل لایه نمایش یا رابط کاربری، لایه اپلیکیشن یا کاربرد که دادهها در آن پردازش میشوند و لایه داده که دادههای مربوط به اپلیکیشن در آنجا ذخیره و مدیریت میشوند.
یک رابط کاربری گرافیکی استاندارد با ماژولهای مختلف روی سرور کاربردی مورد استفاده قرار میگیرد. سامانه مدیریت پایگاهداده رابطهای (Relational Database) روی سرور پایگاهداده، دارای منطق ذخیرهسازی داده در کامپیوتر است. معمولاً لایههای میانی چندلایهای هستند. طبیعت لایههای سهگانه فیزیکی نیست، بلکه منطقی است و به همین دلیل ممکن است این لایهها در سرورهای متفاوتی هم به صورت «راهحلهای داخلی و در محل» (On-Premises Based Solution) و هم به صورت «نرمافزار به عنوان یک سرویس» (Software-as-a-Service | SaaS) اجرا شوند.
آیا معماری سه لایه همچنان استفاده میشود ؟
لایه های معماری سه لایه چه هستند ؟
لایههای معماری سه لایه شامل لایه نمایش (Presentation Layer)، لایه منطق کسبوکار (Business Logic Layer) و لایه پایگاه داده (Database Layer) است. البته، هر یک از این لایههای سهگانه با نامهای دیگری هم خطاب میشوند که در ادامه به آنها نیز اشاره خواهد شد.
این سه لایه در تصویر زیر نشان داده شده است.

در ادامه، توضیحات بیشتری در مورد هر یک از این سه لایه ارائه شده است.
لایه نمایش
هدف اصلی لایه نمایش چیست ؟
لایه اپلیکیشن
این لایه که به آن «لایه میانی»، «لایه منطق کسبوکار» یا «لایه منطق» نیز گفته میشود، قلب یک برنامه کاربردی (نرمافزار) به حساب میآید. در این لایه، اطلاعات دریافتی از لایه نمایش پردازش میشوند. همچنین، لایه اپلیکیشن میتواند دادههای لایه داده را نیز ویرایش یا حذف کند یا داده جدید به لایه داده اضافه کند.
لایه داده
تفاوت معماری سه لایه و MVC چیست ؟
به لحاظ مفهومی، معماری سه لایه خطی (Linear) است. اما، معماری MVC ماهیت مثلثی دارد. یعنی لایه نما بهروزرسانیها را به لایه Controller ارسال میکند؛ Controller لایه مدل را بهروزرسانی میکند و لایه نما به صورت مستقیم توسط مدل بهروزرسانی میشود. البته، الگوی معماری MVC ممکن است لزوماً مثلثی نباشد اما، معماریهای چند لایه و سه لایه همواره خطی هستند. در مورد تفاوت معماری سه لایه و MVC باید گفت که در نگاه اول، لایههای سهگانه ممکن است با مفهوم الگوی معماری مدل، نما و کنترلگر (Model-View-Controller | MVC) یکسان به نظر برسند.

مزایای معماری سه لایه چه هستند ؟
مزیت اصلی معماری سه لایه یا در اصل «معماری سه رده» (Three-Tier)، استقلال و جدایی عملکرد منطقی و فیزیکی در آن است. هر رده یا Tier میتواند در پلتفرم سیستمی و سروری جداگانهای اجرا شود. این پلتفرمها میتوانند هر سرور وب، سرور کاربردی یا سرور پایگاهدادهای باشند که به بهترین نحو با نیازهای عملکردی مورد نیاز سازگاری لازم را داشته باشند.
هر لایه حداقل روی یک سختافزار سرور اختصاصی یا مجازی اجرا میشود تا بتوان خدمات هر لایه را بدون تحت تأثیر قرار دادن سایر لایهها شخصیسازی و بهینهسازی کرد. در این بخش، برخی از مزیتها و فواید اصلی پیادهسازی معماری سه لایه در توسعه نرمافزار فهرست شده است.
- معماری سه لایه برای گروههای توسعه، آزادی کامل را فراهم میکند تا آنها بتوانند تنها بخشهای مشخصی از اپلیکیشن را به طور مستقل و بدون تحت تأثیر قرار دادن کلیت محصول، بهروزرسانی و جایگزین کنند. میتوان مقیاس اپلیکیشن را به راحتی با جدا کردن بخش فرانتاند از پایگاهداده، مطابق نیازهای مشتری تغییر داد.
- میتوان در صورت نیاز، امکانات سختافزاری جدیدی مانند سرورهای تازه را برای رسیدگی به مقادیر عظیم داده و یا برخی خدمات نیازمند منابع حجیم اضافه کرد.
- یک معماری سه لایه میزان انعطافپذیری بیشتری را فراهم میکند؛ برای سازمانهایی که قصد بهکارگیری فناوریهای جدید را داشته باشند.
- در معماری سه لایه با وجود اینکه کل سیستم به طور طبیعی به تغییر و تحول خود ادامه میدهد، میتوان اجزاء حیاتی برنامه کاربردی را محفوظ نگه داشت.
- با استفاده از معماری سه لایه چرخه توسعه یا دفعات بهروزرسانی برنامه کاربردی به طور قابل توجهی بهبود مییابد که این مسئله منجر به حصول اطمینان از عدم بروز تداخل در تجربه کاربری مشتری خواهد شد.
- به جای کار بر روی کل نرمافزار، گروههای مختلف میتوانند روی بخشهای متفاوتی از توسعه برنامه کاربردی مطابق با حوزه تخصصی مربوط به خودشان فعالیت کنند. این مسئله باعث بهبود کارایی و سرعت توسعه نرمافزار میشود.

سایر مزیتها در مقایسه با معماری تک لایه یا دو لایه
سایر مزیتهای معماری سه لایه در مقایسه با معماریهای تک لایه و دولایه شامل موارد زیر است:
- توسعه سریعتر: چون هر لایه را میتوان به صورت همزمان به وسیله تیمهای مختلف توسعه داد، یک سازمان میتواند محصول تولیدی را سریعتر به بازار عرضه کند و برنامهنویسان میتوانند از بهترین و آخرین زبانهای برنامهنویسی برای هر کدام از لایهها استفاده کنند.
- مقیاسپذیری بهبودیافته: در صورت نیاز، میتوان مقیاس هر لایه را از سایر لایهها بهطور مستقل تغییر داد.
- قابلیت اطمینان بیشتر: احتمال کمی وجود دارد که نارسایی در یک لایه موجب بروز اثر مخرب در عملکرد سایر لایهها شود.
- امنیت بیشتر: به دلیل عدم وجود امکان ارتباط مستقیم میان لایه نمایش و لایه داده، یک لایه اپلیکیشن با طراحی مناسب میتواند به عنوان نوعی فایروال داخلی عمل کند تا از تزریق SQL و سایر آسیبپذیریها و رخنهها جلوگیری شود.
کاربرد معماری سه لایه در توسعه وب
در توسعه وب، معماری سه لایه نامهای مختلفی دارد اما عملکرد آن یکسان است. در ادامه، نحوه عملکرد معماری سه لایه در توسعه تحت وب شرح داده شده است.
وب سرور
سرور کاربردی
سرور کاربردی (Application Server) با لایه میانی متناظر است و از منطق کسبوکار مورد استفاده در پردازش دادههای وارد شده توسط کاربر، میزبانی میکند. در مورد مثال کسبوکار الکترونیک، سرور کاربردی همان لایهای است که در پایگاهداده فهرست محصولات را جستجو کرده و موجودی آن را بازمیگرداند یا جزئیاتی را به پروفایل مشتری اضافه میکند. این لایه اغلب با استفاده از پایتون، روبی یا PHP توسعه داده میشود و به برای مثال، از فریمورکهایی مثل Symphony ،Rails ،Django یا ASP.NET استفاده میشود.
سرور پایگاهداده
سرور پایگاهداده، لایه داده یا بکاند یک وباپلیکیشن است. این سرور روی نرمافزارهای پایگاهداده از جمله، DB2 ،Oracle ،MySQL یا PostgreSQL اجرا میشود.
مثال ساده ای از معماری سه لایه
در اینجا، یک مثال ساده برای درک لایههای معماری سه لایه ارائه شده است. در این مثال، اطلاعات یک دانشجو در رکوردهای پایگاهداده وجود دارد. این اطلاعات شامل نام، نشانی، پست الکترونیک و تصویر است.
لایه نمایش
رابط کاربری لایه نمایش میتواند به صورت تصویر زیر باشد.

کدهای لایه نمایش به صورت زیر است:
توضیح کدها
کدهای بالا طراحی ابتدایی یک نمای فرانتاند از برنامه کاربردی را تولید میکنند. همچنین، فراخوانی توابع لایههای دیگر در کدهای لایه نمایش انجام شده است تا لایهها بتوانند با یکدیگر تعامل داشته باشند.
لایه دسترسی کسبوکار
کارکرد لایه کسبوکار به این صورت است که دادهها را از لایه نمایش میپذیرد و آنها را به لایه داده منتقل میکند. در ادامه، برخی موارد مهم در مورد لایه منطق کسبوکار در معماری سه لایه فهرست شده است.
- منطق کسبوکار به عنوان یک رابط میان لایه کلاینت و لایه دسترسی داده عمل میکند.
- کل منطق کسبوکار مثل تایید اعتبار دادهها، محاسبات، درج دادهها یا ویرایش آنها همگی تحت لایه منطق کسبوکار کدنویسی میشوند.
- منطق کسبوکار، برقراری ارتباط میان کلاینت و لایه داده را سریعتر و سادهتر میکند.
- لایه منطق کسبوکار یک جریان کاری مناسب را تعیین میکند. این جریان کاری مناسب، برای تکمیل یک وظیفه ضروری است.
در ادامه، کدهای مربوط به لایه منطق کسبوکار ارائه شده است.
توضیح کدهای نمونه منطق کسبوکار
کدها از تابع لایه منطق کسبوکار استفاده میکنند. این تابع، دادههای لایه اپلیکیشن را دریافت کرده و آن را به لایه داده انتقال میدهد. کدهای لایه منطق به عنوان یک میانجی بین توابع تعریف شده در لایه نمایش و لایه داده عمل میکنند. به این صورت که لایه منطق در درون تابع خود، توابع لایه داده یا لایه نمایش را فراخوانی میکند.
لایه دسترسی داده
در این قسمت، تابع لایه داده نوشته میشود. این تابع، دادهها را از لایه کسبوکار دریافت کرده و عملیات لازم را در پایگاهداده اجرا میکند. کدهای تابع لایه داده در ادامه ارائه شده است.
توضیحات کدهای لایه داده
در کدهای لایه داده، درخواست ارسالی به وسیله سیستم به طور کامل دریافت شده و عملیات لازم در پایگاهداده انجام میشود. در حالی که معماری سه لایه به وضوح پرکاربردترین معماری چند لایه اپلیکیشن به شمار میرود، معماریهای دیگری هم وجود دارند و ممکن است توسعهدهندگان در حین کار یا تحقیق با آنها مواجه شوند. در ادامه، به دو نوع معماری تک لایه و دو لایه پرداخته شده است.
چه زمانی نیاز به معماری سه لایه وجود دارد ؟
دیدگاه سنتی بر این عقیده است که معماری سه لایه یک رویکرد «مناسب» به حساب میآید. اما آیا این باور در دنیای امروزی همچنان پابرجاست؟ برای پاسخگویی به این سوال، بهتر است مسئله را سادهسازی کرده و آنرا فقط در حوزه اینترنت و وباپلیکیشنهایی که از معماری سه لایه استفاده میکنند بررسی کرد.
این وباپلیکیشنها شامل وبسرورهای مستقل از لحاظ فیزیکی (لایه وب | Web-Tier)، سرور کاربردی (لایه میانی | Middle Tier) و پایگاه داده (لایه داده | Data Tier) است. بحث اصلی در نیاز به استفاده از معماری سه لایه پیرامون لایه میانی و لزوم استفاده از آن جریان دارد.
آیا نیازی به استفاده از لایه میانی وجود دارد ؟
در اکثر موارد، به کارگیری معماری سه لایه در توسعه نرمافزار به این مسئله وابسته است که چه هدف و کاربردی برای استفاده از این مدل معماری وجود دارد؟ در ادامه، برخی از استدلالهای موافق و مخالف، پیرامون استفاده از یک سرور کاربردی در لایه میانی مورد بحث و بررسی قرار گرفته است.
امنیت
عملکرد و گسترشپذیری
استفاده مجدد و نگهداری
یک لایه میانی فیزیکی را میتوان بین تعدادی کلاینت به اشتراک گذاشت و در نتیجه قابلیت استفاده مجدد و نگهداری افزایش و بهبود پیدا میکند. اما، یک نقطه نظر مخالف اذعان دارد که این کار را میتوان با ایجاد قطعات قابل استفاده مجدد انجام داد. زیرا، پیادهسازی چند باره این قطعات امکانپذیر است و دیگر نیازی به یک لایه میانی وجود نخواهد داشت.
اهمیت دیدگاه و لزوم سنجش شرایط
یکی دیگر از نظرات مخالف در خصوص استفاده از لایه میانی، افزایش هزینهها و پیچیدگی است. ایجاد یک معماری سه لایه نسبتاً ساده است اما، پیادهسازی صحیح آن نیاز به تلاش قابل توجهی دارد. هنگام تصمیمگیری در خصوص معماری، دیدگاه بسیار دارای اهمیت است. اغلب، دلیل استفاده از یک سرور کاربردی فیزیکی این است که سازمان مربوطه اجازه تبادل ترافیک SQL میان ماشینها در DMZ را نمیدهد. این قطعاً یکی از دلایل عدم استفاده از لایه میانی به حساب میآید، اما در صورتی که واقعاً کاهش هزینهها و پیچیدگی اهمیت داشته باشد، شاید لازم باشد در این خصوص تجدید نظر شود.
کدام مدل معماری اپلیکیشن بهتر است ؟
روز به روز، کسبوکارهای بیشتری با هدف پاسخگویی به نیازهای تکامل یافته مشتریان، به تحول دیجیتال روی میآورند. میزان استفاده مشتریان از شبکههای اجتماعی، اپلیکیشنهای موبایل و فناوریهای دیجیتال بیشتر و بیشتر میشود. به دلیل این تغییرات، راهبرد دیجیتال بخش جداییناپذیری از راهبرد تجارت و کسبوکار به حساب میآید. بسیاری از شرکتها و سازمانها نیاز توان محاسباتی خود را از طریق سرویسها و پلتفرمهای ابری تأمین میکنند. این کار از طریق اینترنت و بهکارگیری یک راهبرد Cloud-First (خدمات ابری در اولویت) برای توسعه اکثر اپلیکیشنها انجام میشود.
این مسئله، طراحی ساختار اپلیکیشنهای قدیمی را دچار تغییر و تحول بیشتری کرده است. قابلیتهای عملکردی و حالتمندی در اولویت قرار داده شده اما، اکنون اکثر کاربردهای مرتبط با مشتری در حال گذار به SaaS و پلتفرمهای دیجیتال هستند. امروزه، تمرکز طراحی اپلیکیشن بیشتر بر تجربه کاربری، بیحالتی (Statelessness) و چابکی (Agility) معطوف شده است. انتخاب صحیح معماری اپلیکیشن به نیازمندیها و مقتضیات یک کسبوکار بستگی دارد. در این بخش، روشهای جایگزین برای رویکرد سنتی معماری سه لایه ارائه شده است. قبل از آن، دلیل نیاز به استفاده از سایر رویکردها و مشکل معماری سه لایه مورد بررسی قرار میگیرد.
مشکل معماری سه لایه چیست ؟
این مسئله باعث میشود که نه تنها اعمال تغییرات معمول با دشواری مواجه شود، بلکه نگهداری از حداقل سه لایه سختافزاری و نرمافزاری میتواند برای یک کسبوکار ناکارآمد باشد. یک مدل معماری سه لایه اغلب با نام معماری یکپارچه (تغییرناپذیر | Monolithic ) نیز شناخته میشود. این روزها چندین مدل معماری جدید وجود دارد که در ادامه، چهار مدل معماری که در عصر خدمات ابری در دسترس هستند، معرفی شده است.

معماری ریز خدمت
مثال معماری ریز خدمت
میتوان یک برنامه کاربردی تجارت الکترونیک را درنظر گرفت که با استفاده از معماری ریزخدمات توسعه داده شده است. هر ریزخدمت میتواند روی یک قابلیت تجاری مجزا (مثل سبد خرید، عملیات جستجو و نظرسنجی مشتریان) متمرکز باشد. هر یک از این قابلیتها میتواند یک خدمت مستقل باشد که با زبان برنامهنویسی متفاوتی نوشته شده، در زیرساخت متفاوتی مستقر شده و توسط تیمهای مختلف مدیریت شده باشد.
مقایسه معماری میکروسرویس و معماری سه لایه
در معماری سه لایه تغییرناپذیر، تمام قطعات تنها به عنوان یک ماژول همزیستی دارند، اغلب توسط یک تیم مدیریت میشوند و همه چیز به هم پیوسته است. اگر نیاز به انجام بهروزرسانی وجود داشته باشد، باید کل اپلیکیشن دوباره مستقر شود که این مسئله سرعت اعمال تغییرات برای اپلیکیشنهای بزرگتر و پیچیدهتر را کاهش میدهد. معمولاً بهترین راهکار برای اپلیکیشنهای کوچکتر، استفاده از معماری سه لایه است.
معماری ابری بومی
در فضای ابری، اپلیکیشنها باید بتوانند به صورت موازی و در چندین گره (نقطه اتصال | Node) اجرا شوند، یک وضعیت (حالت) تنظیمات را به اشتراک بگذارند، یک سازکار رویدادنگاری متمرکز داشته باشند و با استفاده از DevOps و یک پردازش CI/CD قابل استقرار باشند. بسیاری از ارائهدهندگان خدمات ابری شیوهنامههایی را در خصوص توسعه ابری بومی ارائه میدهند.
معماری رویدادگرا بدون سرور
معماری رویدادگرا (Event-Driven Architecture | EDA) مبتنی بر سامانههای جداسازی شده (Decoupled Systems) است که در پاسخ به رویدادها اجرا میشوند. یک معماری رویدادگرا از رویدادها برای تحریک و ارتباط میان خدمات جداسازی شده استفاده میکند. EDA سابقه طولانی دارد، اما در حال حاضر در فضای ابری اعتبار بیشتری پیدا کرده است. اگر از EDA به درستی استفاده شود، میتواند افزایش چشمگیری در چابکی، صرفهجویی در هزینهها و مزایای عملیاتی به همراه داشته باشد.
EDA توزیع شده بدون سرور، میتواند توابعی را اجرا کند که به صورت خودکار مقیاسبندی شده و در پاسخ به یک REST API یا یک رویداد فعال میشوند. در مورد مدل بدون سرور، نیاز به هیچ عملیات مدیریت سروری وجود ندارد. مدل بدون سرور نیز به سرعت قابل گسترش و مقیاسپذیری است که این مسئله منجربه امکان بهروزرسانی و استقرار سریع میشود. همچنین، این معماری بدون حالت است. برخی از خدمات بدون سرور موجود که از جانب فراهمکنندگان خدمات ابری مختلف ارائه شدهاند، در تصویر زیر ملاحظه میشود.

در ادامه، انواع معماری بدون سرور معرفی شده است.
انواع معماری بدون سرور
فهرست انواع معماری بدون سرور به صورت زیر است:
- توابع به عنوان خدمت (Functions as a Service | FaaS) : آپلود قطعات دارای قابلیت عملکردی در فضای ابری و فراهم کردن امکان اجرای این قطعات به صورت مستقل
- بکاند به عنوان خدمت (Backend as a Service | BaaS) : بهکارگیری خدمات از یک شخص ثالث، خدماتی مانند مدیریت اپلیکیشن، مدیریت پایگاهداده و ذخیرهسازی ابری
- بکاند همراه به عنوان یک خدمت (Mobile Backend as a Service | MBaaS): قابلیتهایی برای اپلیکیشنهای موبایل
معماری مبتنی بر فناوری ابری
چگونه میتوان کاری کرد که یک کاربرد مبتنی بر معماری سه لایه در یک محیط ابری به خوبی کار کند؟ معماری مبتنی بر فناوری ابری در بهترین حالت برای ساخت یک کاربرد امروزی (وبسایتهای ایستا/پویا)، استقرار یک وباپلیکیشن، اتصال به یک پایگاهداده و تحلیل رفتار کاربر مناسب است. یک معماری سنتی مبتنی بر فناوری ابری شامل متعادل کننده بار ترافیکی، وبسرورها، سرورهای کاربردی و پایگاهدادهها است.
API Gateway
API Gateway یک سرویس مهم برای توسعهدهندگان جهت ایجاد و انتشار APIهای ایمن در معماری مبتنی بر فضای ابری محسوب میشود. این API به عنوان یک درب ورود برای اپلیکیشنها جهت دسترسی به دادهها و منطق کسبوکار است. همچنین، API Gateway کار تایید اعتبار و مدیریت دسترسی را انجام میدهد. توسعهدهندگان از API Gateway برای فراخوانی کارکردهای مختلف بدون سرور در فراخوانیهای API مختلف استفاده میکنند.
چطور میتوان تصمیم گرفت کدام معماری برای یک کاربرد خاص بهتر است ؟
تصمیمی که در زمان انتخاب مدل معماری گرفته میشود، میتواند به موفقیت یا شکست پروژه منجر شود. بنابراین، تصمیمگیری باید بر اساس ملزومات کاربردی گرفته شود. برای مثال، سفرهای کوتاه نیازی به استفاده از هواپیما ندارند. بنابراین، قبل از انتخاب یک معماری برای یک کاربرد خاص نرمافزاری، باید موارد زیر را در نظر گرفت:
- آیا اولویت با معماری سه لایه تغییرناپذیر است یا معماری ریزخدمت؟ (برای پروژههای کوچکتر با ملزومات اپلیکیشن ساده، روش معماری سه لایه انتخاب بهتری است)
- آیا تیم توسعه آمادگی لازم برای استفاده از معماری ریزخدمات را دارد؟
- آیا تیم توسعه در حال حاضر یک پروسه CI/CD و DevOps مبتنی بر فناوری ابری دارد؟
- مدل میزبانی چیست؟ خصوصی، عمومی یا ترکیبی است؟
- معماری اپلیکیشن چگونه پروژه را تحت تأثیر قرار میدهد؟
- آیا ترکیبی از چند مدل معماری پاسخگوی نیازها هست؟
اکنون، تقریباً تمام مبحث پیرامون معماری سه لایه پوشش داده شده و زمان آن فرا رسیده است تا توضیحات مختصری درباره سایر مدلهای معماری چند لایه ارائه شود.
معماری دو لایه
معماری دو لایه (Two-Tier Architecture) مشابه معماری کلاینت سرور است که در آن، ارتباط میان کلاینت و سرور رخ میدهد. در این نوع از معماری نرمافزار، لایه نمایش یا رابط کاربری در سمت کلاینت اجرا میشود. در حالی که، لایه پایگاهداده در سمت سرور اجرا و ذخیره میشود. هیچ لایه منطق کسبوکار یا لایه مشخصی بین کلاینت و سرور وجود ندارد.
در واقع، منطق کسبوکار یا در داخل لایه نمایش، یا لایه داده و یا در هر دو قرار میگیرد. در معماری دو لایه، رده نمایش و در نتیجه کاربر نهایی، به لایه داده دسترسی مستقیم دارند و معمولاً منطق کسبوکار محدود است. مثالی از یک معماری دو لایه میتواند یک برنامه کاربردی مدیریت مخاطبین باشد که کاربران میتوانند در آن دادههای مخاطبین را دریافت یا وارد کنند.
معماری تک لایه
سادهترین معماری ممکن محسوب میشود چرا که، متناظر با اجرای اپلیکیشن روی یک رایانه شخصی است. در معماری تک لایه (در اصل تک رده یا One-Tier)، تمام قطعات مورد نیاز برای اجرای یک اپلیکیشن روی یک برنامه کاربردی یا سرور قرار دارد. در واقع در چنین معماری، لایههای سهگانه نمایش، منطق کسبوکار و لایه داده همگی روی یک ماشین (دستگاه) واقع شدهاند.
مزایا و معایب معماریهای چند لایه
در این بخش، مزایا و معایب معماری چند لایه در جدول زیر ارائه شده است.
| مزایا | معایب |
| قابلیت گسترشپذیری | افزایش حجم کار و تلاش |
| صحت دادهها | افزایش پیچیدگی |
| قابلیت استفاده مجدد | |
| توزیع تقلیلیافته | |
| امنیت بهبود یافته | |
| دسترسپذیری بهتر |
بنابراین، رمزگذاری مسائل کسبوکار جهان واقعی و نحوه بهروزرسانی، ایجاد، ذخیره یا تغییر دادهها برای انجام وظایف به طور کامل، بخشی از معماری یک نرم افزار به حساب میآید.
نکاتی در مورد معماری چند لایه
با در نظر داشتن این مسئله که متخصصین نرمافزار باید کنترل کاملی روی لایههای معماری داشته باشند، نکاتی در مورد معماری چند لایه در ادامه فهرست شده است.
- با استفاده از روشی مانند soap XML باید سعی شود تا جای ممکن هر لایه از لایه دیگر جدا شود.
- میتوان برخی از ابزارهای خودکار را برای ایجاد نگاشت میان لایه منطق کسبوکار و لایه پایگاهداده رابطهای (لایه داده) به کار گرفت. از جمله ابزارهایی که میتوانند به مدلسازی این روشهای نگاشتی کمک کنند، میتوان به فریمورک Entity و Hibernate برای .NET اشاره کرد.
- میتوان در لایه نمایش یک کد رایج برای همه کلاینتها در یک کتابخانه مجزا قرار داد. این کار امکان استفاده مجدد از کدها را برای انواع کلاینتها بیشینه میکند.
- یک لایه حافظه پنهان میتواند در یک لایه موجود اضافه شود تا سرعت عملکرد را بهبود دهد.
معماری سه لایه در سی شارپ
در این مثال، یک اپلیکیشن ویندوز کوچک برای واکشی داده از پایگاهداده با استفاده از معماری سه لایه پیادهسازی شده است. در این مثال، دادهها از تنها یک جدول به نام «شخص» (Person) خوانده میشوند.
کدهای مربوط به لایه دسترسی داده
پیادهسازی این پروژه کوچک با لایه دسترسی داده شروع میشود. در کدهای زیر، یک تابع برای خواندن داده از پایگاهداده ایجاد شده است:
دو تابع با نام یکسان و پیادهسازی متفاوت (Overloaded Function) در کدهای بالا ایجاد شده است. یک تابع هیچ آرگومانی دریافت نخواهد کرد و سایر توابع، دادهها را با استفاده از شناسه واکشی خواهند کرد.
ایجاد لایه منطق کسبوکار
اکنون یک لایه منطق کسبوکار برای ارتباط با لایه نمایش و لایه دسترسی داده ایجاد خواهد شد. کدهای مربوط به لایه کسبوکار در ادامه ارائه شده است.
ایجاد لایه نمایش
در این بخش، لایه نمایش ایجاد میشود که بالاترین لایه محسوب شده و از طریق آن کاربر با سیستم به تعامل میپردازد. مطابق تصویر زیر یک پنجره ساده ایجاد میشود:

این فُرم دارای یک شبکه داده (DataGrid)، یک محفظه متن (TextBox) و یک دکمه است. در رویداد بارگذاری این فرم، تمام دادهها در DataGrid نمایش داده خواهند شد. عملیات دیگری هم وجود دارد که در آن کاربر میتواند یک شخص خاص را با داشتن شناسهاش از پایگاه داده بیرون بکشد. کدهای مربوط به لایه نمایش در ادامه آمده است.
ساختار کامل پروژه به صورت تصویر زیر است:


در صورتی که قصد جستجو برای شخص خاصی وجود داشته باشد، آنگاه باید شناسه شخص مربوطه را در محفظه ورود داده وارد کرد تا رکورد مربوط به شخص مورد نظر نمایش داده شود:

ساختار جدول به صورت زیر است. این جدول شامل سه بخش (فیلد) شناسه (ID)، نام و نام خانوادگی است. نام جدول نیز Person است. در ادامه این مطلب، فیلمهای آموزش معماری سه لایه ارائه شده است که یکی از این فیلمهای آموزشی نیز مربوط به پیادهسازی معماری سه لایه در سیشارپ است.

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














بابا بنازم به این آموزش
خدا وکیلی آدم آموزشم میذاره یا به کسی آموزش میده اینجوری کار کنه
دمت گرم استاد خدا قوت
در بحث معماری سیستم(system architecture) معماری ترکیبی به چه معناست؟با ذکر مثال توضیح دهید
خیلی عالی بود ممنون
با سلام و احترام؛
صمیمانه از همراهی شما با مجله فرادرس و ارائه بازخورد سپاسگزاریم.
برای شما آرزوی سلامتی و موفقیت داریم.