Hissə 2. Proqramın arxitekturasından bir az danışaq

Bu material “ Müəssisələrin İnkişafına Giriş ” seriyasının bir hissəsidir . Şəbəkə haqqında birinci hissə buradadır . Proqram təminatının arxitekturası onun əsasında proqramın yaradıldığı və bütün proqramın modulları və komponentlərinin qarşılıqlı əlaqədə olduğu strukturdur. Proqramçılar çox uzun müddətdir ki, yaxşı memarlıq yaratmağa çalışırlar, buna görə də təəccüblü deyil ki, biz indi çoxlu memarlıq nümunələri bilirik. Onları başa düşmək lazımdır: veb proqram yazarkən arxitektura problemi kəskinləşir, çünki onun tərkibində adi proqramdan daha çox komponent və modul var. Memarlıq nümunəsi bəzi proqram təminatının dizayn problemini həll etmək üçün artıq düşünülmüş bir yoldur. Yəqin ki, siz artıq Zavod metodu, Abstract Factory, Builder, Prototype, Singleton və bəlkə də başqaları kimi dizayn nümunələri ilə rastlaşmısınız. Onlar sadəcə kod yazmaq, siniflər yaratmaq və qarşılıqlı əlaqəni planlaşdırmaq üçün istifadə olunur. Memarlıq nümunələri daha yüksək abstraksiya səviyyəsində - proqram istifadəçisinin server, verilənlər və layihənin digər komponentləri ilə qarşılıqlı əlaqəsini planlaşdırarkən istifadə olunur. Gəlin bəzi şablonlara və onlardan necə istifadə olunacağına qısa nəzər salaq.

Müştəri-server arxitekturası

Adından belə bir təəssürat yaranır ki, bu mövzuda hər şey sadə və aydındır. Ancaq gəlin bəzi məqamları aydınlaşdıraq ki, şərti Baharı öyrənməyə başlayanda nədən danışdığımızı dəqiq başa düşəsiniz. Deyək ki, siz söhbət yazdınız və siz və dostunuz ondan istifadə etməyə başlayırsınız. Burada sadə bir seçim mümkündür - bildiyiniz IP ünvanlarından istifadə edərək birbaşa İnternet vasitəsilə bir-birinizə mesaj göndərirsiniz: Əvvəlcə hər şeyin yaxşı olduğu görünə bilər, ta ki başqa bir dostunuz sualı ilə görünənə qədər: “Niyə məni söhbətinə əlavə etmirsən? Söhbətə ortaq dost əlavə etmək qərarına gəldikdə isə, arxitektura problemi ilə qarşılaşırsınız: hər bir söhbət istifadəçisi istifadəçilərin sayı haqqında məlumatı yeniləməli, yeni istifadəçinin İP ünvanını əlavə etməlidir. Mesaj göndərərkən bütün iştirakçılara çatdırılmalıdır. Bunlar ortaya çıxacaq ən bariz problemlərdir. Kodun özündə daha çox problem gizlənəcək. Onların qarşısını almaq üçün istifadəçilər haqqında bütün məlumatları saxlayacaq və onların ünvanlarını bilən serverdən istifadə etməlisiniz . Mesaj yalnız serverə göndərilməlidir. O da öz növbəsində mesajı bütün alıcılara göndərəcək. Söhbətinizə bir server tərəfi əlavə etmək qərarına gəldikdə, müştəri-server arxitekturasını qurmağa başlayacaqsınız.

Müştəri-server arxitekturasının komponentləri

Gəlin onun nə olduğunu anlayaq. Müştəri-server arxitekturası dizayn nümunəsidir, veb proqramların yaradılması üçün əsasdır. Bu arxitektura üç komponentdən ibarətdir:

1. Müştəri - adından məlum olur ki, bu, müəyyən məlumat əldə etmək üçün serverlə əlaqə saxlayan xidmətin (veb tətbiqinin) istifadəçisidir.

2. Server veb proqramınızın və ya onun server hissəsinin yerləşdiyi yerdir. O, istifadəçilər haqqında lazımi məlumatlara sahibdir və ya tələb edə bilər. Həmçinin, müştəri əlaqə saxladıqda, server tələb olunan məlumatı qaytarır.

3. Şəbəkə sadədir: müştəri ilə server arasında məlumat mübadiləsini təmin edir.

Server müxtəlif istifadəçilərdən çoxlu sayda sorğuları emal edə bilər. Yəni, çoxlu müştəri ola bilər və onlar bir-biri ilə məlumat mübadiləsi aparmalı olsalar, bu, server vasitəsilə həyata keçirilməli olacaq. Beləliklə, server daha bir əlavə funksiya alır - trafikə nəzarət. Yaratdığımız çox istifadəçi söhbətindən danışırıqsa, bütün proqram kodu iki moduldan ibarət olacaq:

• müştəri - avtorizasiya, mesajların göndərilməsi/qəbul edilməsi üçün qrafik interfeysi ehtiva edir;

• server tərəfi - serverdə yerləşdirilən və istifadəçilərdən mesajlar qəbul edən, onları emal edən və sonra alıcılara göndərən veb proqram.

İnternetdə faydalı (və ya o qədər də faydalı olmayan) məlumatlara baxmaq istədikdə biz brauzeri açır, axtarış çubuğuna sorğu daxil edirik və cavab olaraq axtarış sistemindən məlumat alırıq. Bu zəncirdə brauzer bizim müştərimizdir. O, serverə axtardığımız barədə məlumatı olan sorğu göndərir. Server sorğunu emal edir, ən uyğun nəticələri tapır, onları brauzer (müştəri) üçün başa düşülən formatda paketləyir və geri göndərir. Axtarış sistemləri kimi mürəkkəb xidmətlərdə çoxlu serverlər ola bilər. Məsələn, avtorizasiya serveri, məlumat axtarmaq üçün server, cavab yaratmaq üçün server. Ancaq müştəri bu barədə heç nə bilmir: onun üçün server vahid bir şeydir. Müştəri yalnız giriş nöqtəsini, yəni sorğu göndərməli olduğu serverin ünvanını bilir. Əvvəlki hissədə baxdığımız tətbiqi xatırlayaq - real vaxt rejimində bütün ölkələrdə orta hava istiliyinə nəzarət etmək üçün. Onun arxitekturası belə görünəcək: Tətbiqimiz serverdə yerləşir. Tutaq ki, hər beş saniyədən bir yerli hidrometeoroloji mərkəzlərin serverlərinə sorğular göndərir, onlardan konkret ölkədəki temperatur haqqında məlumat alır və bu məlumatları saxlayır. Müştəri “dünyadakı cari hava istiliyinə baxmaq” sorğusu ilə bizimlə əlaqə saxladıqda, biz ölkə üzrə çeşidlənmiş ən son saxlanılan məlumatları qaytarırıq. Beləliklə, tətbiqimiz həm serverdir (istifadəçi sorğularını emal edərkən), həm də müştəridir (digər serverlərdən məlumat aldıqda). Sadə bir müştəri-server arxitekturası çox nadir hallarda və yalnız çox sadə proqramlar üçün istifadə olunur. Həqiqətən böyük və mürəkkəb layihələr üçün gələcəkdə daha çox tanış olacağınız müxtəlif növ arxitekturalardan istifadə olunur. Hələlik isə müştəri-server modelinə çox bənzəyən modelə baxaq.

Üç səviyyəli memarlıq

Bu, üçüncü oyunçunu təqdim edən memarlıq nümunəsidir : məlumat anbarı . Bu nümunədən istifadə edərkən üç səviyyə adətən təbəqə adlanır:

1. Müştəri təbəqəsi istifadəçi interfeysidir. Bu, HTML səhifələrinin göndərildiyi veb brauzer və ya JavaFX istifadə edərək yazılmış GUI proqramı ola bilər. Əsas odur ki, onun köməyi ilə istifadəçi serverə sorğu göndərə və onun cavablarını emal edə bilər.

2. Məntiq qatı sorğuların/cavabların işləndiyi serverdir. Onu tez-tez server təbəqəsi də adlandırırlar. Bütün məntiqi əməliyyatlar da burada baş verir: riyazi hesablamalar, məlumat əməliyyatları, digər xidmətlərə zənglər və ya məlumatların saxlanması.

3. Məlumat təbəqəsi verilənlər bazası serveridir: serverimiz ona daxil olur. Bu təbəqə proqramın əməliyyat zamanı istifadə etdiyi bütün lazımi məlumatları saxlayır.

Beləliklə, serverimiz istifadəçiyə birbaşa daxil olmaq imkanı vermədən məlumatlara daxil olmaq üçün bütün öhdəlikləri öz üzərinə götürür.

Üç səviyyəli arxitekturanın üstünlükləri

Belə bir arxitekturadan istifadə edərək bir çox üstünlüklər əldə edirik, o cümlədən:

1. SQL inyeksiyalarına qarşı qorunma qurmaq bacarığı SQL kodunun ötürüldüyü serverə hücumdur və bu kod icra edildikdə təcavüzkar bizim verilənlər bazamıza təsir edə bilər.

2. İstifadəçi girişini tənzimləmək istədiyimiz məlumatların sərhədlənməsi.

3. Məlumatı müştəriyə göndərməzdən əvvəl dəyişdirmək imkanı.

4. Ölçeklenebilirlik - tətbiqimizi eyni verilənlər bazasından istifadə edəcək bir neçə serverə genişləndirmək imkanı.

5. İstifadəçinin əlaqə keyfiyyətinə daha az tələblər. Serverdə cavab yaradanda biz tez-tez verilənlər bazasından çoxlu müxtəlif məlumatlar götürürük, onu formatlayırıq, yalnız istifadəçiyə lazım olanı buraxırıq. Bu yolla biz müştəriyə cavab olaraq göndərdiyimiz məlumatların miqdarını azaldırıq.

Memarlıq nümunələrindən nə qədər tez-tez istifadə etməlisiniz?

Əgər siz, məsələn, Fabrika Metodunun dizayn nümunəsi ilə tanışsınızsa , yəqin ki, ondan nə vaxt istifadə edəcəyinizi düşünmüsünüz. Bəzən nə edəcəyinə qərar vermək çətindir: yeni operatordan istifadə edərək və ya zavod metodundan istifadə edərək obyekt yaradın. Ancaq zaman keçdikcə anlayış gəlir. Memarlıq nümunələri ilə hər şey bir az fərqlidir. Müəssisə çərçivələri proqramçının ümumi qəbul edilmiş bəzi nümunəyə əsaslanan layihə yaratmaq üçün onlardan istifadə etməsi üçün nəzərdə tutulmuşdur. Buna görə də, Bahar Çərçivəsini öyrənməzdən əvvəl, müştəri-server arxitekturasının, üç səviyyəli arxitekturanın və MVC arxitekturasının nə olduğunu mütləq başa düşməlisiniz. Narahat olmayın: MVC arxitekturasından sonra danışacağıq. Hissə 1. Spring və JavaEE 3-cü hissəni öyrənməzdən əvvəl bilməli olduğunuz şey. HTTP/HTTPS protokolları Hissə 4. Maven əsasları Hissə 5. Servletlər. Sadə veb proqramın yazılması Hissə 6. Servlet konteynerləri Hissə 7. MVC (Model-View-Controller) nümunəsinin təqdimatı Hissə 8. Kiçik yaylı yükləmə proqramının yazılması