با استفاده از آزمایش رایگان 10 روزه O'Reilly به الگوهای معماری نرم افزار و 60 هزار عنوان دیگر دسترسی کامل داشته باشید.

همچنین رویدادهای آنلاین زنده، محتوای تعاملی، مواد آماده سازی گواهینامه و موارد دیگر وجود دارد.

فصل 1. معماری لایه ای

رایج ترین الگوی معماری، الگوی معماری لایه ای است که به عنوان الگوی معماری n-tier شناخته می شود. این الگو استاندارد واقعی برای اکثر برنامه های جاوا EE است و بنابراین به طور گسترده توسط اکثر معماران، طراحان و توسعه دهندگان شناخته شده است. الگوی معماری لایه‌ای کاملاً با ارتباطات سنتی فناوری اطلاعات و ساختارهای سازمانی موجود در اکثر شرکت‌ها مطابقت دارد و آن را به یک انتخاب طبیعی برای اکثر تلاش‌های توسعه برنامه‌های کاربردی تجاری تبدیل می‌کند.

الگو و توضیحات

اجزای درون الگوی معماری لایه‌ای در لایه‌های افقی سازمان‌دهی شده‌اند، که هر لایه نقش خاصی را در برنامه انجام می‌دهد (به عنوان مثال، منطق ارائه یا منطق تجاری). اگرچه الگوی معماری لایه ای تعداد و انواع لایه هایی را که باید در الگو وجود داشته باشد مشخص نمی کند، اکثر معماری های لایه ای از چهار لایه استاندارد تشکیل شده اند: ارائه، کسب و کار، تداوم و پایگاه داده (شکل 1-1). در برخی موارد، لایه تجاری و لایه تداوم در یک لایه تجاری واحد ترکیب می شوند، به ویژه زمانی که منطق پایداری (به عنوان مثال، SQL یا HSQL) در اجزای لایه تجاری تعبیه شده است. بنابراین، برنامه های کاربردی کوچکتر ممکن است تنها سه لایه داشته باشند، در حالی که برنامه های تجاری بزرگتر و پیچیده تر ممکن است دارای پنج لایه یا بیشتر باشند.

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

شکل 1-1. الگوی معماری لایه ای

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

مفاهیم کلیدی

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

شکل 1-2. لایه های بسته و درخواست دسترسی

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

لایه های مفهوم انزوا به این معنی است که تغییرات ایجاد شده در یک لایه از معماری به طور کلی تأثیر نمی گذارد یا مؤلفه های موجود در لایه های دیگر را تحت تأثیر قرار نمی دهد: این تغییر به اجزای موجود در آن لایه جدا شده است ، و احتمالاً یک لایه مرتبط دیگر (مانند یک لایه پایدار حاویSQL). اگر اجازه دسترسی مستقیم به لایه ارائه به لایه پایداری را بدهید ، سپس تغییراتی که به SQL در لایه پایداری ایجاد شده است ، هم بر لایه تجاری و هم در لایه ارائه تأثیر می گذارد ، در نتیجه یک برنامه بسیار محکم همراه با بسیاری از وابستگی های متقابل بین مؤلفه ها ایجاد می کند. سپس این نوع معماری برای تغییر بسیار سخت و گران می شود.

لایه های مفهوم انزوا همچنین به این معنی است که هر لایه مستقل از لایه های دیگر است ، از این طریق آگاهی کمی از عملکرد درونی سایر لایه ها در معماری دارد. برای درک قدرت و اهمیت این مفهوم ، یک تلاش بزرگ برای تغییر شکل برای تبدیل چارچوب ارائه از JSP (صفحات سرور جاوا) به JSF (چهره های سرور جاوا) در نظر بگیرید. با فرض اینکه قراردادها (به عنوان مثال ، مدل) مورد استفاده بین لایه ارائه و لایه تجاری یکسان باقی مانده است ، لایه تجاری تحت تأثیر اصلاح مجدد قرار نمی گیرد و کاملاً مستقل از نوع چارچوب رابط کاربر مورد استفاده در لایه ارائه است.

در حالی که لایه های بسته لایه های انزوا را تسهیل می کنند و به همین دلیل به منزوی کردن تغییر در معماری کمک می کنند ، مواقعی وجود دارد که باز شدن لایه های خاص معقول است. به عنوان مثال ، فرض کنید می خواهید یک لایه خدمات مشترک را به یک معماری اضافه کنید که حاوی مؤلفه های خدمات مشترکی است که توسط مؤلفه های موجود در لایه تجاری قابل دسترسی است (به عنوان مثال ، کلاس های داده و رشته های رشته ای یا کلاس های حسابرسی و ورود به سیستم). ایجاد یک لایه خدمات معمولاً در این حالت ایده خوبی است زیرا از نظر معماری دسترسی به خدمات مشترک به لایه تجاری (و نه لایه ارائه) را محدود می کند. بدون یک لایه جداگانه ، هیچ معماری از نظر معماری وجود ندارد که لایه ارائه را از دسترسی به این خدمات مشترک محدود کند و مدیریت این محدودیت دسترسی را دشوار می کند.

در این مثال ، لایه خدمات جدید احتمالاً در زیر لایه تجاری قرار دارد تا نشان دهد که اجزای موجود در این لایه خدمات از لایه ارائه قابل دسترسی نیستند. با این حال ، این مشکلی ایجاد می کند که اکنون لایه تجاری برای رسیدن به لایه پایداری ، از لایه خدمات استفاده می کند ، که به هیچ وجه معنی ندارد. این یک مشکل قدیمی با معماری لایه بندی شده است و با ایجاد لایه های باز در معماری حل می شود.

همانطور که در شکل 1-3 نشان داده شده است ، لایه خدمات در این حالت به صورت باز مشخص شده است ، به این معنی که درخواست ها مجاز به دور زدن این لایه باز هستند و مستقیماً به لایه زیر آن می روند. در مثال زیر ، از آنجا که لایه خدمات باز است ، اکنون به لایه تجاری اجازه می دهد تا آن را دور بزند و مستقیماً به لایه پایداری برود ، که این امر کاملاً منطقی است.

شکل 1-3. لایه ها را باز کنید و جریان را درخواست کنید

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

نمونه الگو

برای نشان دادن نحوه عملکرد معماری لایه بندی شده ، درخواست کاربر تجاری را برای بازیابی اطلاعات مشتری برای یک فرد خاص همانطور که در شکل 1-4 نشان داده شده است ، در نظر بگیرید. فلش های سیاه درخواست را برای بازیابی داده های مشتری به پایگاه داده نشان می دهند و فلش های قرمز پاسخ را نشان می دهند که به صفحه نمایش داده می شود تا داده ها را نمایش دهد. در این مثال ، اطلاعات مشتری هم از داده های مشتری و هم از داده های سفارش (سفارشات قرار داده شده توسط مشتری) تشکیل شده است.

صفحه مشتری وظیفه پذیرش درخواست و نمایش اطلاعات مشتری را بر عهده دارد. این نمی داند که داده ها کجاست ، چگونه بازیابی می شود ، یا برای دریافت داده ها چه تعداد جداول پایگاه داده باید پرس و جو باشد. هنگامی که صفحه مشتری درخواست دریافت اطلاعات مشتری را برای یک فرد خاص دریافت کرد ، سپس آن درخواست را به ماژول نماینده مشتری ارسال می کند. این ماژول مسئول دانستن اینکه کدام ماژول ها در لایه تجاری می توانند آن درخواست را پردازش کنند و همچنین نحوه رسیدن به آن ماژول و چه داده هایی به آن نیاز دارد (قرارداد). هدف مشتری در لایه تجاری وظیفه جمع آوری کلیه اطلاعات مورد نیاز درخواست کسب و کار را دارد (در این مورد برای به دست آوردن اطلاعات مشتری). این ماژول برای به دست آوردن داده های مشتری ، ماژول DAO (Data Access Object) را در لایه پایداری و همچنین ماژول سفارش DAO برای دریافت اطلاعات سفارش فراخوانی می کند. این ماژول ها به نوبه خود عبارات SQL را برای بازیابی داده های مربوطه اجرا می کنند و آن را به شیء مشتری در لایه تجاری منتقل می کنند. هنگامی که شیء مشتری داده ها را دریافت کرد ، داده ها را جمع می کند و آن اطلاعات را به نماینده مشتری منتقل می کند ، که سپس آن داده ها را به صفحه مشتری منتقل می کند تا به کاربر ارائه شود.

شکل 1-4. مثال معماری لایه ای

از دیدگاه فناوری ، به معنای واقعی کلمه ده ها روش قابل اجرا در این ماژول ها وجود دارد. به عنوان مثال ، در پلت فرم جاوا ، صفحه مشتری می تواند یک سرور (JSF) باشد که سرور Java با صفحه نمایش همراه با نماینده مشتری به عنوان مؤلفه لوبیا مدیریت شده روبرو می شود. هدف مشتری در لایه تجاری می تواند یک لوبیای بهاری محلی یا لوبیای EJB3 از راه دور باشد. اشیاء دسترسی به داده ها که در مثال قبلی نشان داده شده اند می توانند به صورت ساده Pojo (اشیاء قدیمی جاوا قدیمی) ، پرونده های Mybatis XML Mapper یا حتی اشیاء محاصره تماس JDBC خام یا پرس و جوهای خواب زمستانی اجرا شوند. از دیدگاه Microsoft Platform ، صفحه مشتری می تواند یک ماژول ASP (صفحات سرور فعال) با استفاده از . NET Framework برای دسترسی به ماژول های C# در لایه تجارت ، با ماژول های دسترسی مشتری و سفارش داده شده به عنوان ADO (ActiveX Data Objects) باشد.

ملاحظات

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

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

هر معماری لایه ای حداقل برخی از سناریوها را در اختیار دارد که در معماری ضد الگوی سینک سوراخ قرار می گیرند. با این حال ، نکته اصلی تجزیه و تحلیل درصد درخواست هایی است که در این گروه قرار می گیرند. قانون 80-20 معمولاً یک عمل خوب برای تعیین اینکه آیا شما در حال تجربه معماری ضد الگوی سینک سوراخ هستید یا خیر ، دنبال می شود. این معمولی است که حدود 20 درصد از درخواست ها را به عنوان پردازش ساده عبور و 80 درصد از درخواست هایی که دارای برخی منطق تجاری در ارتباط با درخواست هستند ، داشته باشد. با این حال ، اگر فهمیدید که این نسبت معکوس شده است و اکثر درخواست های شما پردازش ساده از طریق آن است ، ممکن است بخواهید برخی از لایه های معماری را باز کنید ، با توجه به اینکه کنترل تغییر به دلیل دشوارتر خواهد بودعدم انزوای لایه.

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

تجزیه و تحلیل الگو

جدول زیر حاوی رتبه بندی و تجزیه و تحلیل ویژگی های معماری مشترک برای الگوی معماری لایه بندی شده است. امتیاز برای هر ویژگی مبتنی بر تمایل طبیعی برای آن ویژگی به عنوان یک توانایی مبتنی بر اجرای معمولی الگوی و همچنین آنچه که الگوی به طور کلی برای آن شناخته شده است ، است. برای مقایسه جانبی در مورد چگونگی ارتباط این الگوی با سایر الگوهای موجود در این گزارش ، لطفاً در پایان این گزارش به پیوست A مراجعه کنید.

درجه بندی چابکی کلی: تحلیل کم: چابکی کلی توانایی پاسخ سریع به یک محیط دائما در حال تغییر است. در حالی که می‌توان تغییر را از طریق لایه‌های ویژگی جداسازی این الگو جدا کرد، اما ایجاد تغییرات در این الگوی معماری به دلیل ماهیت یکپارچه اکثر پیاده‌سازی‌ها و همچنین اتصال شدید اجزاء که معمولاً با این الگو یافت می‌شوند، همچنان دست و پاگیر و زمان بر است. الگو. سهولت در استقرار رتبه: تجزیه و تحلیل کم: بسته به نحوه اجرای این الگو، استقرار می تواند به یک مشکل تبدیل شود، به ویژه برای برنامه های بزرگتر. یک تغییر کوچک در یک مؤلفه می‌تواند مستلزم استقرار مجدد کل برنامه (یا بخش بزرگی از برنامه) باشد که منجر به استقرارهایی می‌شود که باید در ساعات غیرفعال یا آخر هفته‌ها برنامه‌ریزی، برنامه‌ریزی و اجرا شوند. به این ترتیب، این الگو به راحتی خود را به سمت یک خط لوله تحویل مداوم نمی‌برد و رتبه کلی برای استقرار را بیشتر کاهش می‌دهد.

رتبه آزمایش پذیری: تجزیه و تحلیل بالا: از آنجایی که اجزا به لایه های خاصی در معماری تعلق دارند، لایه های دیگر را می توان مسخره یا خرد کرد، آزمایش این الگو نسبتاً آسان است. یک توسعه‌دهنده می‌تواند یک مؤلفه ارائه یا صفحه نمایش را برای جداسازی آزمایش در یک مؤلفه تجاری مسخره کند، و همچنین لایه تجاری را برای آزمایش عملکردهای خاص صفحه نمایش مسخره کند. رتبه‌بندی عملکرد: تحلیل پایین: در حالی که درست است که برخی از معماری‌های لایه‌ای می‌توانند عملکرد خوبی داشته باشند، این الگو به دلیل ناکارآمدی نیاز به گذر از چندین لایه معماری برای برآورده کردن یک درخواست تجاری، خود را به برنامه‌های با کارایی بالا نمی‌دهد. رتبه بندی مقیاس پذیری: تحلیل کم: به دلیل گرایش به پیاده سازی های محکم و یکپارچه از این الگو، برنامه هایی که با استفاده از این الگوی معماری ساخته می شوند، به طور کلی مقیاس پذیری دشواری دارند. شما می توانید یک معماری لایه ای را با تقسیم لایه ها به استقرارهای فیزیکی جداگانه یا تکثیر کل برنامه در چندین گره مقیاس بندی کنید، اما به طور کلی جزئیات بسیار گسترده است و مقیاس آن را گران می کند. رتبه سهولت توسعه: تجزیه و تحلیل بالا: سهولت توسعه امتیاز نسبتاً بالایی را دریافت می کند، بیشتر به این دلیل که این الگو بسیار شناخته شده است و اجرای آن خیلی پیچیده نیست. از آنجایی که اکثر شرکت‌ها برنامه‌های کاربردی را با جداسازی مجموعه مهارت‌ها بر اساس لایه‌ها (ارائه، کسب‌وکار، پایگاه داده) توسعه می‌دهند، این الگو به یک انتخاب طبیعی برای اکثر توسعه‌های برنامه‌های تجاری تبدیل می‌شود. ارتباط بین ارتباطات و ساختار سازمانی یک شرکت و روشی که آن نرم افزار را توسعه می دهد، همان چیزی است که قانون کانوی نامیده می شود. برای دریافت اطلاعات بیشتر در مورد این همبستگی جذاب، می توانید «قانون کانوی» را در گوگل جستجو کنید.

اکنون الگوهای معماری نرم افزار را با پلتفرم یادگیری O'Reilly دریافت کنید.

اعضای O'Reilly آموزش آنلاین زنده، به‌علاوه کتاب، ویدیو و محتوای دیجیتالی از نزدیک به 200 ناشر را تجربه می‌کنند.