سلام
من می خواستم یک سری اطلاعات راجع به معماری هفت لایه بدست بیارم امید وارم شما به من کمک کنید!
چی هست؟
چه فرقی با بقیه داره ؟
سلام
من می خواستم یک سری اطلاعات راجع به معماری هفت لایه بدست بیارم امید وارم شما به من کمک کنید!
چی هست؟
چه فرقی با بقیه داره ؟
بسه دیگه . این لایه ها کی تموم میشن ؟ چرا هی زیاد میشید . باوار کنید بالاتر از 3 لایه دیگه منطقی نیست . نمی دونم شاید بعضیها برای کلاس کار یا نمی دونم چه دلیلی هی لایه از خودشون در میارن . میشه بالاتر از3 لایه رو یکی بگه آخه چی است . لایه امنیت هم که بعضیها اضافه میکنند عملا مسخرس .
دوست عزیز لطفا از بحث های غیر فنی پرهیز کنید . مسخرس است یعنی چی ؟!!نوشته شده توسط ali_kolahdoozan
در جواب دوست عزیز آقا یا خانم Leo_messi باید عرض کنم معماری 3 لایه استاندارد که تحت Pattern شرکت آی بی ام برای اولین بار عرضه شد و سپس توسط دیگر شرکتها بسط داده شد شامل 3 لایه : UI , Biz , DataAccess هست بعدها به علت ایراداتی که محققین به این معماری گرفتن که جای بحث طولانی داره شرکت سان لایه Biz رو به دو لایه BizFacade , BizRule تقسیم کرد و معماری 4 لایه رو بوجود آورد اصطلاحا به این معماری فاکتوری Factory هم میگن . بعد از اون مایکروسافت 1 لایه Common هم به این معماری اضافه کرد که در همه 4 لایه قابل دسترسی بود . یعنی اگه این 4 لایه قبل زیر هم قرار میگرفتند این لایه Common به صورت یک ستون در کنار لایه ها قرار میگرفت و در واقع معماری 5 لایه شکل گرفت . بعد از اون یک لایه Security هم دقیقا مثل لایه Common به صورت یک ستون و قابل دسترس در تمام لایه ها به اون اضافه شد و این معماری رو کامل تر کرد . لایه 7 ام رو در اکثر Pattern ها لایه Exception Handler می دونن که باز هم مثل لایه Common عمل میکنه . جدیدا هم که با ظهور معماری های SOA لایه هشتمی روی کل این لایه ها کشیده میشه که مثل یک سرویس عمل میکنه و اساسا یک سرویس است و امکان ارتباط یک Application رو با دنیای خارج میده
هر لایه می تونه از طریق سرویس با لایه های دیگه ارتباط برقرار بکنه، یعنی Service به صورت یک Interface استفاده میشه، پس دیگه چه نیازی هست که سرویس بصورت سراسری روی کل لایه ها کشیده بشه؟!با ظهور معماری های SOA لایه هشتمی روی کل این لایه ها کشیده میشه که مثل یک سرویس عمل میکنه و اساسا یک سرویس است و امکان ارتباط یک Application رو با دنیای خارج میده
وَ سَيَعْلَمُ الَّذِينَ ظَلَمُوا [آل محمد حقهم] أَيَّ مُنْقَلَبٍ يَنْقَلِبُونَ - الشعراء (227)
و ظالمین [حق آل محمد (ص) ] به زودی خواهند دانست که به کدام بازگشتگاه بازخواهند گشت.
با سلام
اگه بتونی یه شکل بزاری یا یه سمپل با دات نت یا یه سایت ممنون میشم (اسم این معماری چی هست) خیلی ممنون میشم پیشاپیش از شما تشکر میکنم
در معماری SOA چیزی که اهمیت فراوانی داره ارتباط App های مجزا با هم طبق یک قرارداد قابل تنظیم با سرعت قابل قبول مستقل از پروتکل ها و نوع زبان برنامه نویسی App ها و رعایت encapsulation هست .
فرض کنید بنده و شما دو برنامه مستقل از هم در دو زبان برنامه نویسی مثلا جاوا و دات نت برای یک سازمان یا حتی دو سازمان متفاوت نوشتیم که عملا مستقل از هم هستند ولی در بعضی مواقع برنامه ها نیازمند ارتباط با هم هستند . مسلما شما اگه بنده رو مستقیما با لایه مثلا Biz یا UI خودتون مرتبط کنید چندان خوشایند طرفین نیست ! هم برای شما که مجبورید سورس رو به نحوی فاش کنید هم بنده که مجبورم ساعتها وقتم رو روی فانکشن ها و کلاسهای شما بزارم تا ببینم شما چه کردید و چه نکردید مخصوصا در سیستمهای بزرگ که ممکنه Biz Layer حجیم و پیچیده ای داشته باشند این مشکل بیشتر به چشم میاد .
اینجاست که بحث یک لایه سرویس دهنده بر روی کل لایه های شما پیش میاد . با این کار برنامه های دیگر رو از درگیر شدن با لایه های زیرین برنامه خودتون منع کردید و هم پشتیبانی راحت تری رو میشه ارایه داد .
البته نقطه نظرات متفاوت هست و میشه این نوع معماری ها رو با توجه به نوع کاربرد بسط داد
این میشه همون Interface.در معماری SOA چیزی که اهمیت فراوانی داره ارتباط App های مجزا با هم طبق یک قرارداد قابل تنظیم با سرعت قابل قبول مستقل از پروتکل ها و نوع زبان برنامه نویسی App ها و رعایت encapsulation هست .
بحث من اینه که در این شرایط باید هر لایه خودش یک Interface برای ارتباط با لایه های دیگه یا با برنامه های دیگه فراهم کنه، حالا این Interface می تونه مثلا به صورت یک WebService باشه، اما برداشت من از پست شما اینه که باید یک لایه وجود داشته باشه که Interface همه لایه ها برای ارتباط با برنامه های دیگر در آن تعریف شده باشه، مثلا یک لایه که توش هم رابطی برای ارتباط با Business Logic هست، هم رابطی برای Presentation، هم رابطی Database و غیره.اینجاست که بحث یک لایه سرویس دهنده بر روی کل لایه های شما پیش میاد . با این کار برنامه های دیگر رو از درگیر شدن با لایه های زیرین برنامه خودتون منع کردید و هم پشتیبانی راحت تری رو میشه ارایه داد .
من از عبارت "لایه سرویس دهنده بر روی کل لایه ها" همچین نتیجه گیری می کنم.
وَ سَيَعْلَمُ الَّذِينَ ظَلَمُوا [آل محمد حقهم] أَيَّ مُنْقَلَبٍ يَنْقَلِبُونَ - الشعراء (227)
و ظالمین [حق آل محمد (ص) ] به زودی خواهند دانست که به کدام بازگشتگاه بازخواهند گشت.
هر دو نقطه نظر به نوعی می تونه کاربرد داشته باشه در مورد اولی که فرمودید یک مثال معروف میشه به physical Approach Pattern اشاره کرد که لایه ها به صورت فیزیکی از هم جدا هستند . فرض کنید لایه UI شما سمت Client و لایه Biz شما بر روی یک سرور قوی و لایه DA شما هم بر روی یک سرور قوی دیگه عمل کنه . در واقع دستورات به سرور لاجیک شما توسط یک سرویس فرستاده میشه اونجا عملیات با سرعت بالا انجام میشه و نتیجه که حاوی اطلاعات نهایی هست به کلاینت با فرمت مثلا Xml فرستاده میشه . در این روش هر لایه به نوعی یک اینترفیس داره و یک سری سرویسها رو از لایه های بالاتر از خودش میگیری و به اون جواب میده .
در مورد نقطه نظر دومی هم فرض کنید برنامه ای برای مثلا 10 منطقه از شهری یا کشوری نوشتید که اطلاعات جدا ای رو پردازش میکنند و هر منطقه DB و Server و ... خودشو داره ولی نیازمند ارتباط با دیگر مناطق هم در بعضی موارد هست . اینجاست که یک لایه Wrapper از سرویس بر روی کل معماری میتونه خیلی کمک کنه و ارتباط بین مناطق رو از طریق یک اینترفیس ساده سرویس و نه لاجیک پیچیده هر منطقه فراهم کنه
مسئله اینه که در این حالت هم یک نرم افزار نیاز نداره تمام لایه های خودش را در یک سرویس به اشتراک بزاره، فقط باید متناسب با نوع درخواست یک لایه را به اشتراک بزاره، مثلا در مثال شما، وقتی Business Layer یک منطقه نیاز به انجام یکسری عملیات یا یکسری بازرسی ها در سطح منطقه دیگه داره، کافیه به Business Layer اون منطقه یا به Presentation آن متصل بشه، ولی نیازی نداره که در کنار آن مستقیما به لایه DB هم دسترسی داشته باشه. یکی از علت های چند لایه کردن نرم افزارها افزایش سطح Abstraction بین بخش های مختلف نرم افزار و Encapsulation هست، در این صورت وجود یک لایه سرویس که رابطی برای کل لایه ها فراهم بکنه منطقی به نظر نمی رسه.در مورد نقطه نظر دومی هم فرض کنید برنامه ای برای مثلا 10 منطقه از شهری یا کشوری نوشتید که اطلاعات جدا ای رو پردازش میکنند و هر منطقه DB و Server و ... خودشو داره ولی نیازمند ارتباط با دیگر مناطق هم در بعضی موارد هست . اینجاست که یک لایه Wrapper از سرویس بر روی کل معماری میتونه خیلی کمک کنه و ارتباط بین مناطق رو از طریق یک اینترفیس ساده سرویس و نه لاجیک پیچیده هر منطقه فراهم کنه
در هر حال خیلی ممنون
وَ سَيَعْلَمُ الَّذِينَ ظَلَمُوا [آل محمد حقهم] أَيَّ مُنْقَلَبٍ يَنْقَلِبُونَ - الشعراء (227)
و ظالمین [حق آل محمد (ص) ] به زودی خواهند دانست که به کدام بازگشتگاه بازخواهند گشت.
دقیقا منظور من هم همین بود . شما وقتی یک لایه wrapper از سرویس بر روی کل لایه ها داشته باشید تنها کاری که لازمه انجام بدید به اشتراک گذاری لایه سرویس هست و بس ! چرا که از طریق این لایه میشه به همه لایه ها به صورت abstrac دسترسی داشت .
آخ اینطوری نرم فزاری که به سیستم ما متصل میشه، می تونه به هر لایه ایی که خواست در هر سطحی دسترسی داشته باشه، اون وقت باید یک سطح Authentication هم برای این کار بزاریم، البته حتی در این صورت هم حداقل Interface سایر لایه ها در اختیار فردی که نیازی به آنها نداره قرار میگیره.شما وقتی یک لایه wrapper از سرویس بر روی کل لایه ها داشته باشید تنها کاری که لازمه انجام بدید به اشتراک گذاری لایه سرویس هست و بس ! چرا که از طریق این لایه میشه به همه لایه ها به صورت abstrac دسترسی داشت .
وَ سَيَعْلَمُ الَّذِينَ ظَلَمُوا [آل محمد حقهم] أَيَّ مُنْقَلَبٍ يَنْقَلِبُونَ - الشعراء (227)
و ظالمین [حق آل محمد (ص) ] به زودی خواهند دانست که به کدام بازگشتگاه بازخواهند گشت.
اولا چرا فکر میکنید اون نرم افزار به هر لایه ای که خواست و در هر سطحی می تونه وصل بشه ؟!
مگه نه اینکه معماری ما چند لایه است ؟ پس زمانی که ما بالاترین لایه که در اینجا سرویس ماست رو در اختیار یک نرم افزار دیگه میزاریم اون شخص یا نرم افزار فقط به اون سرویس دسترسی داره و لایه های زیرین از دید لایه های بالا مخفی هستند . مثلا شما سرویسی دارید به نام GetDebitCustomers که لیست مشتریان بدهکار رو برمیگردونه من به عنوان شخص ثالث میتونم از این سرویس شما اگه اجازه داشته باشم استفاده کنم ولی نمیتونم به کد لایه Biz شما که لایه زیر لایه سرویس هست و GetDebitCustomers در اونجا نوشته شده دسترسی داشته باشم . در واقع لایه سرویس یک entry point هست و نه Biz شما
دوما اگه شما نمخواهید همه سرویس ها رو در اختیار بزارید همون سرویس هایی که دوست دارید رو در لایه سرویس به صورت global قرار بدید . این یک مساله خاص هست و اصل مساله رو زیر سوال نمی بره . در واقع این شمایید که باید برای case خودتون یک راه حل مناسب پیدا کنید وگرنه اصل قضیه معماری SOA (سرویس گرا) الان به عنوان یک اصل در طراحی و توسعه سیستمهای نر افزاری پذیرفته شده و شرکتهایی مثل سان و مایکروسافت هم در ویرایش جدید محصولاتشون بشدت دارن از این Pattern ها پشتیبانی میکنن
بحث سر SOَA نبود. بحث سر این بود که چرا باید این لایه روی تمام لایه ها کشیده بشه. تصور من از توضیحات قیلی شما این هست که یک لایه برای سرویس در نظر گرفته بشه که Interface تمام لایه ها در آن موجود باشد. سوال من هم با توجه به این پیش فرض مطرح شد که، چرا باید یک لایه شامل تمامی Interface های تمام لایه ها باشد؟اصل قضیه معماری SOA (سرویس گرا) الان به عنوان یک اصل در طراحی و توسعه سیستمهای نر افزاری پذیرفته شده و شرکتهایی مثل سان و مایکروسافت هم در ویرایش جدید محصولاتشون بشدت دارن از این Pattern ها پشتیبانی میکنن
مثلا، Business Logic با Presentation از یک طرف و با DB از طرف دیگر، از طریق یک سرویس در ارتباط است. یک نرم افزار 3rd Party هم می خواد با Business Logic سیستم ما ارتباط برقرار کند، برای این کار کافی هست که ما Interface مربوط به سرویس Biz-Presentation را در اختیار آن نرم افزار قرار بدیم، نیازی نیست که یک رابط در اختیار آن قرار بدیم که هم شامل Interface مربوط به Biz-Presentation هست، هم DB-Biz.
بحث من هم بر سر به اشتراک گذاشتن Interface ها بود، نه اینکه نرم افزار 3rd Party میتونه به سورس لایه های بالاتر دسترسی داشته باشه!
شاید من منظور شما از اینکه "لایه سرویس بر روی سایر لایه ها کشیده میشه"، را درست متوجه نمیشم!
وَ سَيَعْلَمُ الَّذِينَ ظَلَمُوا [آل محمد حقهم] أَيَّ مُنْقَلَبٍ يَنْقَلِبُونَ - الشعراء (227)
و ظالمین [حق آل محمد (ص) ] به زودی خواهند دانست که به کدام بازگشتگاه بازخواهند گشت.
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول