قسمت 2. بیایید کمی در مورد معماری نرم افزار صحبت کنیم

این مطالب بخشی از مجموعه " مقدمه ای بر توسعه سازمانی " است. بخش اول در مورد شبکه اینجا است . معماری نرم افزار ساختاری است که بر اساس آن یک برنامه کاربردی ایجاد می شود و ماژول ها و اجزای کل برنامه با هم تعامل دارند. برنامه نویسان برای مدت طولانی سعی کرده اند معماری خوبی ایجاد کنند، بنابراین جای تعجب نیست که ما اکنون الگوهای معماری زیادی را می شناسیم. شما باید آنها را درک کنید: وقتی یک برنامه وب می نویسید، مشکل معماری حاد می شود، زیرا اجزا و ماژول های بیشتری در آن نسبت به یک برنامه معمولی وجود دارد. یک الگوی معماری روشی است که از قبل فکر شده برای حل برخی از مشکلات طراحی نرم افزار است. احتمالاً قبلاً با الگوهای طراحی مانند Factory Method، Abstract Factory، Builder، Prototype، Singleton و شاید موارد دیگر مواجه شده اید. از آنها برای نوشتن کد، ایجاد کلاس ها و برنامه ریزی نحوه تعامل آنها استفاده می شود. الگوهای معماری در سطح بالاتری از انتزاع استفاده می شود - هنگام برنامه ریزی تعامل کاربر برنامه با سرور، داده ها و سایر اجزای پروژه. بیایید نگاهی گذرا به برخی از قالب ها و نحوه استفاده از آنها بیاندازیم.

معماری سرویس گیرنده-سرور

از نام این تصور به دست می آید که همه چیز در مورد این موضوع ساده و واضح است. اما اجازه دهید نکاتی را روشن کنیم تا وقتی شروع به مطالعه بهار مشروط می کنید، دقیقاً متوجه شوید که در مورد چه چیزی صحبت می کنیم. فرض کنید یک چت نوشتید و شما و دوستتان شروع به استفاده از آن کردید. یک گزینه ساده در اینجا امکان پذیر است - شما مستقیماً از طریق اینترنت با استفاده از آدرس های IP که می دانید برای یکدیگر پیام ارسال می کنید: در ابتدا ممکن است به نظر برسد که همه چیز خوب کار می کند تا زمانی که یکی دیگر از دوستان شما با این سؤال ظاهر شود: "چرا دان من را به چت خود اضافه می کنید؟ و هنگامی که تصمیم می گیرید یک دوست مشترک را به چت اضافه کنید، با یک مشکل معماری مواجه می شوید: هر کاربر چت باید اطلاعات مربوط به تعداد کاربران را به روز کند، آدرس IP کاربر جدید را اضافه کند. و هنگام ارسال پیام باید به تمامی شرکت کنندگان تحویل داده شود. اینها بدیهی ترین مشکلاتی است که پیش خواهد آمد. مشکلات بسیار بیشتری در خود کد پنهان خواهند شد. برای اجتناب از آنها، باید از سروری استفاده کنید که تمام اطلاعات کاربران را ذخیره کند و آدرس آنها را بداند. پیام فقط باید به سرور ارسال شود. و او نیز به نوبه خود پیام را برای همه گیرندگان ارسال می کند. هنگامی که تصمیم می گیرید سمت سرور را به چت خود اضافه کنید، شروع به ساخت معماری سرویس گیرنده-سرور خواهید کرد.

اجزای معماری مشتری-سرور

بیایید بفهمیم او چیست. معماری سرویس گیرنده-سرور یک الگوی طراحی است که اساس ایجاد برنامه های کاربردی وب است. این معماری از سه جزء تشکیل شده است:

1. مشتری - از نام مشخص می شود که این کاربر یک سرویس (برنامه وب) است که برای به دست آوردن اطلاعاتی با سرور تماس می گیرد.

2. سرور مکانی است که برنامه وب یا قسمت سرور آن در آن قرار دارد. او صاحب اطلاعات لازم در مورد کاربران است یا می تواند آن را درخواست کند. همچنین، هنگامی که یک کلاینت تماس می گیرد، سرور اطلاعات درخواستی را برمی گرداند.

3. شبکه ساده است: تبادل اطلاعات بین مشتری و سرور را تضمین می کند.

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

• مشتری - شامل یک رابط گرافیکی برای مجوز، ارسال / دریافت پیام.

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

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

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

این یک الگوی معماری است که بازیکن سوم را معرفی می کند: انبار داده . هنگام استفاده از این الگو، سه سطح معمولاً لایه نامیده می شوند:

1. لایه مشتری رابط کاربری است. این می تواند یک مرورگر وب باشد که صفحات HTML به آن ارسال می شود یا یک برنامه رابط کاربری گرافیکی که با استفاده از JavaFX نوشته شده است. نکته اصلی این است که با کمک آن کاربر می تواند درخواست ها را به سرور ارسال کند و پاسخ های آن را پردازش کند.

2. لایه منطق سروری است که درخواست ها/پاسخ ها روی آن پردازش می شوند. اغلب به آن لایه سرور نیز می گویند. تمام عملیات منطقی نیز در اینجا انجام می شود: محاسبات ریاضی، عملیات داده، تماس با سایر سرویس ها یا ذخیره سازی داده ها.

3. لایه داده سرور پایگاه داده است: سرور ما به آن دسترسی دارد. این لایه تمام اطلاعات لازم را که برنامه در حین کار استفاده می کند ذخیره می کند.

بنابراین، سرور ما تمامی تعهدات دسترسی به داده ها را بدون اینکه به کاربر اجازه دسترسی مستقیم به آنها را بدهد، بر عهده می گیرد.

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

با استفاده از چنین معماری، مزایای زیادی به دست می آوریم، از جمله:

1. توانایی ایجاد حفاظت در برابر تزریق SQL حمله به سروری است که در آن کد SQL منتقل می شود و زمانی که این کد اجرا می شود، مهاجم می تواند پایگاه داده ما را تحت تأثیر قرار دهد.

2. محدود کردن داده هایی که می خواهیم دسترسی کاربر را به آنها تنظیم کنیم.

3. امکان تغییر داده ها قبل از ارسال به مشتری.

4. مقیاس پذیری - توانایی گسترش برنامه ما بر روی چندین سرور که از یک پایگاه داده استفاده می کنند.

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

هر چند وقت یکبار باید از الگوهای معماری استفاده کنید؟

اگر مثلاً با الگوی طراحی Factory Method آشنا هستید ، احتمالاً به این فکر کرده اید که چه زمانی از آن استفاده کنید. گاهی اوقات تصمیم گیری برای انجام کاری دشوار است: ایجاد یک شی با استفاده از اپراتور جدید یا با استفاده از روش کارخانه. اما با گذشت زمان، درک فرا می رسد. با الگوهای معماری، همه چیز کمی متفاوت است. چارچوب های سازمانی برای برنامه نویس طراحی شده اند تا از آنها برای ایجاد یک پروژه بر اساس برخی الگوهای پذیرفته شده استفاده کند. بنابراین، قبل از یادگیری Spring Framework، قطعاً باید بدانید که معماری مشتری-سرور، معماری سه لایه و معماری MVC چیست. نگران نباشید: بعداً در مورد معماری MVC صحبت خواهیم کرد. قسمت 1. آنچه شما باید قبل از یادگیری Spring و JavaEE قسمت 3 بدانید. پروتکل های HTTP/HTTPS قسمت 4. اصول Maven قسمت 5. Servlets. نوشتن یک برنامه وب ساده قسمت 6. ظروف Servlet قسمت 7. معرفی الگوی MVC (Model-View-Controller) قسمت 8. نوشتن یک برنامه کوچک فنری بوت