Tətbiqetmə yanaşması fəlsəfələri
şəlalə yaxınlaşması
Tətbiqin həyata keçirilməsi üçün şəlalə yanaşması dizaynerdən son istifadəçi təşkilatının bir və ya bir neçə nümayəndəsi ilə məsləhətləşməyi və tətbiqin bütün spesifikasiyalarını yazmağı tələb edir. Tipik olaraq, spesifikasiyalar son istifadəçinin sənədləri asanlıqla oxuya və başa düşə bildiyi şəkildə yazılmış funksional sənədlər və ya istifadə halları toplusunda gəlir.
Son istifadəçi bu sənədləri imzalayır və sənədlər daha sonra tətbiqi dizayn edən texniki dizayn qrupu tərəfindən toplanır, sinif model diaqramları, vəziyyət diaqramları, fəaliyyət diaqramları və məlumat modelləri kimi müxtəlif artefaktlar yaradır. Bu mərhələnin məqsədi hər şeyi o qədər ətraflı yazmaqdır ki, tərtibatçı lazımi kodu yaratmaqda çətinlik çəkməsin. Dizaynın inkişaf qrupuna və sınaq qrupuna rəsmi təhvil verilməsi var. Çatdırıldıqdan sonra inkişaf qrupu kodlaşdırmaya başlayır və test qrupu test nümunələri və sınaq ssenariləri yaratmaq üçün istifadə halları ilə birlikdə texniki dizayndan istifadə edir.
İnkişaf qrupu kodlaşdırmanı bitirdikdən sonra kod test qrupuna təhvil verilir. Test qrupu tələblərə və ətraflı dizayna əsasən hazırladığı testləri həyata keçirir. Bütün problemlər inkişaf qrupu tərəfindən həll ediləcək. Sınaq və fiksasiya prosesi başa çatdıqdan sonra ərizə qəbul testi üçün son istifadəçiyə çatdırılır. Son istifadəçi tətbiqin ilkin tələblərə uyğun olub-olmadığını yoxlamaq üçün son yoxlama aparır. Təsdiqlənərsə, hazır məhsulu təsdiqləyir və layihə tamamlanır. İnkişaf qrupu kodlaşdırmanı bitirdikdən sonra kod test qrupuna təhvil verilir.
Test qrupu tələblərə və ətraflı dizayna əsasən hazırladığı testləri həyata keçirir. Bütün problemlər inkişaf qrupu tərəfindən həll ediləcək. Sınaq və fiksasiya prosesi başa çatdıqdan sonra ərizə qəbul testi üçün son istifadəçiyə çatdırılır. Son istifadəçi tətbiqin ilkin tələblərə uyğun olub-olmadığını yoxlamaq üçün son yoxlama aparır. Təsdiqlənərsə, hazır məhsulu təsdiqləyir və layihə tamamlanır. İnkişaf qrupu kodlaşdırmanı bitirdikdən sonra kod test qrupuna təhvil verilir. Test qrupu tələblərə və ətraflı dizayna əsasən hazırladığı testləri həyata keçirir.
Bütün problemlər inkişaf qrupu tərəfindən həll ediləcək. Sınaq və fiksasiya prosesi başa çatdıqdan sonra ərizə qəbul testi üçün son istifadəçiyə çatdırılır. Son istifadəçi tətbiqin ilkin tələblərə uyğun olub-olmadığını yoxlamaq üçün son yoxlama aparır. Təsdiqlənərsə, hazır məhsulu təsdiqləyir və layihə tamamlanır.
Son istifadəçi tətbiqin ilkin tələblərə uyğun olub-olmadığını yoxlamaq üçün son yoxlama aparır. Təsdiqlənərsə, hazır məhsulu təsdiqləyir və layihə tamamlanır. Son istifadəçi tətbiqin ilkin tələblərə uyğun olub-olmadığını yoxlamaq üçün son yoxlama aparır. Təsdiqlənərsə, hazır məhsulu təsdiqləyir və layihə tamamlanır.
Şəlalə yanaşmasından istifadə edərkən layihənin daha çox və ya daha az fazaları ola bilər, lakin əsas xüsusiyyət hər bir mərhələnin çox formal başlanğıcı və sonu, çox rəsmi nəticələrlə başa çatmasıdır.
Şəlalə yanaşmasının üstünlüyü ondan ibarətdir ki, hər bir mərhələyə cavabdeh olan komandanın məsuliyyəti daha böyükdür. Nə çatdırmalı olduqları, nə vaxt çatdırmalı olduqları və kimə çatdırmalı olduqları aydındır. Çox vaxt inkişaf komandasının istifadəçi ilə qarşılıqlı əlaqəyə ehtiyacı olmayacaq. İnkişafı başqa bir ölkəyə təhvil verərkən bu çox faydalı ola bilər.
Şəlalə yanaşmasının əsas çatışmazlığı ondan ibarətdir ki, hər şeyin çox formal şəkildə təşkil edildiyi bir mühitdə dəyişikliklərə cavab vermək çevikliyi azalır. Hətta hərəkət təşkil etmək lazımdır. Çox az şirkət bunu effektiv şəkildə edir, bu da çox vaxt əlavə məsrəflərin əhəmiyyətli dərəcədə artması ilə nəticələnir. Layihənin xərclərini idarə etmək üçün bəzi şirkətlər hətta tələblərə edilən hər hansı dəyişikliyi ilkin tətbiqin çatdırılmasına qədər gecikdirir və son istifadəçinin ehtiyaclarına cavab verməyən tətbiqi effektiv şəkildə çatdırır.
çevik inkişaf
Uzun müddət davam edən bir çox proqram təminatı layihələri büdcəni aşdı və məhsulu vaxtında çatdırmadı. Çevik proqram təminatının inkişaf etdirilməsi fəlsəfəsinin əsası, adətən bir həftədən dörd həftəyə qədər davam edən iterasiya adlanan qısa müddətli qutularda proqram təminatını inkişaf etdirməklə riski minimuma endirməkdir. Hər bir iterasiya öz miniatür proqram layihəsinə bənzəyir və yeni funksionallığın artırılması üçün lazım olan bütün tapşırıqları ehtiva edir: planlaşdırma, tələblərin təhlili, dizayn, kodlaşdırma, sınaq və sənədləşdirmə. İterasiya məhsulun buraxılmasına zəmanət vermək üçün kifayət qədər funksionallıq əlavə etməsə də, çevik proqram layihəsi hər iterasiyanın sonunda yeni proqram təminatı buraxmağı hədəfləyir. Hər iterasiyanın sonunda komanda layihənin prioritetlərini yenidən qiymətləndirir.
Çevik proqram təminatının inkişafının məqsədi faydalı proqram təminatının sürətli və davamlı çatdırılması vasitəsilə müştəri məmnuniyyətinə nail olmaqdır; həmişə müştərinin ehtiyac duyduğu şeyi qurmağı hədəfləmək; tələblərə gec dəyişikliklərə qarşı çıxmaq əvəzinə, alqışlayın; mütəmadi olaraq dəyişən şəraitə uyğunlaşmaq; üzbəüz söhbətin ən yaxşı ünsiyyət forması olduğu sahibkarlar və tərtibatçılar arasında sıx və gündəlik əməkdaşlıq etmək.
Çevik proqram təminatının inkişafının əsas üstünlüyü dəyişikliklərlə işləməkdə çeviklikdir, həmişə biznes ehtiyaclarına uyğun olaraq çatdırmağı hədəfləyir. Mənfi cəhət, əlbəttə ki, əhatə dairəsinin, planlaşdırmanın və büdcənin idarə edilməsinin mürəkkəbliyinin artmasıdır. Digər ümumi risk (texniki) sənədlərə diqqətin məhdud olmasıdır.
Artan inkişaf
Artan proqram təminatı çevik və şəlalə inkişafının qarışığıdır. Tətbiq mərhələli şəkildə tərtib edilir, həyata keçirilir və sınaqdan keçirilir ki, hər bir artım son istifadəçiyə çatdırılsın. Son artım tamamlanana qədər layihə tamamlanmır. O, aralıq artımları müəyyən etməklə və çevik inkişafın bəzi üstünlüklərindən istifadə etməklə kaskadı qısaltmaq məqsədi daşıyır. Əvvəlki artım üzrə alınan rəyə əsasən, növbəti artımı çatdırarkən düzəlişlər edilə bilər. Növbəti artım həm yeni koddan, həm də əvvəllər verilmiş koda edilən dəyişikliklərdən ibarət ola bilər.
Üstünlük ondan ibarətdir ki, rəsmiyyətlər yerində qalır, lakin dəyişikliklərin idarə edilməsi daha asan olur. Tətbiqin bir neçə dəfə sınaqdan keçirilməsi və yerləşdirilməsinin dəyəri onu bir dəfə etməkdən daha çox olacaq.
Proqram axınına nəzarət
Proqram axınına nəzarət üçün bir yanaşma seçmək çox memarlıq məsələsidir. Məqsəd, funksionallıq və kod əlavə etməyə başladıqdan sonra hər şeyin öz yeri kimi göründüyü tətbiqinizin planını yaratmaqdır. Əgər siz nə vaxtsa yüksək keyfiyyətli kodu nəzərdən keçirmisinizsə və ya yazmısınızsa, bu prinsipi başa düşürsünüz.
Təşkilatçı kodu
Proqram axınının layihələndirilməsində ilk addım tətbiqin planını və ya konturunu yaratmağa kömək etmək üçün bir sıra qaydalar yaratmaqla kodu təşkil etməkdir. Kod məntiqi yerdə yerləşdiyi üçün texniki qulluq, sazlama və səhvlərin düzəldilməsi daha asan olacaq. Əsas işləri gördükdən sonra tətbiqinizin məntiqini həyata keçirmək üçün bir yanaşma seçə bilərsiniz.
Dizayn nümunələri proqram axınına nəzarətin dizaynında mühüm rol oynamalıdır. Bu illər ərzində çoxlu kodlar yazılmış və təkrarlanan problemlər üçün bir çox həll yolları hazırlanmışdır. Bu həllər dizayn nümunələrində yerləşdirilir. Ümumi proqram dizayn probleminə dizayn nümunəsinin tətbiqi asanlıqla tanınan və həmyaşıdlarınız tərəfindən həyata keçirilə bilən həllər yaratmağa kömək edəcək. Unikal problemlər hələ də unikal həllər tələb edəcək, lakin siz onları həll etmək üçün dizayn nümunələrindən istifadə edə bilərsiniz.
Layihənin yaradılması
təbəqələr
İlk addım məntiqi təbəqələri nəzərdən keçirməkdir. Qeyd edək ki, təbəqələr təbəqələrlə eyni deyil, tez-tez qarışdırılır və ya hətta eyni hesab olunur.
qatlara qarşı təbəqələr
Layers kodunuzda sərhədlər yaratmaq üçündür. Üst təbəqənin aşağıdakı təbəqələrdəki koda istinadları ola bilər, lakin bir təbəqənin yuxarıdakı təbəqədəki koda istinadı heç vaxt ola bilməz. Səviyyələr birdən çox kompüter arasında səviyyələrin fiziki paylanmasına aiddir. Məsələn, üç səviyyəli proqramda UI masa üstü kompüterdə işləmək üçün nəzərdə tutulmuşdur, proqram məntiqi proqram serverində işləmək üçün hazırlanmışdır və verilənlər bazası verilənlər bazası serverində işləyir. təbəqə bir neçə təbəqədən ibarət ola bilər.
Şəkil 8-1: Əsas üç səviyyəli təşkilat
Laylar abstraksiya səviyyələrinə aiddir. Şəkil 8-1-də göstərilən təbəqələr əksər tətbiqlər üçün doğrudur. Bu səviyyələrə üç əsas təbəqə də deyilir və müxtəlif başqa adlar da ola bilər. Bir qayda olaraq, təqdimat qatındakı kod tətbiqin məntiqi səviyyəsindəki xidmətləri çağıra bilər, lakin tətbiqin məntiqi səviyyəsi təqdimat qatındakı metodu çağırmamalıdır. Təqdimat təbəqəsi heç vaxt birbaşa məlumat giriş səviyyəsini çağırmamalıdır, çünki bu, tətbiq məntiqi təbəqəsi tərəfindən həyata keçirilən məsuliyyətlərdən yan keçəcəkdir. Məlumata giriş səviyyəsi heç vaxt tətbiq məntiqi qatını çağırmamalıdır.
Laylar sadəcə abstraksiyadır və yəqin ki, təbəqələri həyata keçirməyin ən asan yolu layihənizdə qovluqlar yaratmaq və müvafiq qovluğa kod əlavə etməkdir. Daha faydalı bir yanaşma, hər bir təbəqəni ayrı bir layihəyə yerləşdirmək və bununla da ayrı-ayrı məclislər yaratmaq olardı. Tətbiq məntiqinizi kitabxana yığıncağına yerləşdirməyin faydası ondan ibarətdir ki, o, məntiqi yoxlamaq üçün Microsoft Visual Studio və ya NUnit proqramlarından istifadə edərək vahid testləri yaratmağa imkan verəcək. O, həmçinin hər bir təbəqənin harada yerləşdiriləcəyini seçməkdə çeviklik yaradır.
Fiziki təbəqələr
Müəssisə tətbiqində eyni məntiq üçün birdən çox müştərinin olmasını gözləyərdiniz. Əslində, tətbiqi müəssisə tətbiqi edən onun üç qatda yerləşdirilməsidir: müştəri, proqram serveri və verilənlər bazası serveri. Şirkətinizin satış şöbəsi tərəfindən yaradılmış Microsoft Office Access proqramı satış şöbəsi üçün çox vacib olsa da, korporativ proqram deyil.
Nəzərə alın ki, proqram məntiqi və verilənlərə çıxış təbəqələri tez-tez proqram serverində birlikdə yerləşdirilir. Layihənin dizaynının bir hissəsi uzaqdan .NET və ya Veb xidmətlərindən istifadə edərək proqram serverinə daxil olmağın seçimidir. Hansı birini seçsəniz, təqdimat qatında uzaqdan xidmətlərə asanlıqla daxil olmaq üçün bəzi kodlar əlavə edəcəksiniz. Tətbiq serverinizdə xidmətlərə daxil olmaq üçün veb xidmətlərindən istifadə edirsinizsə, Visual Studio .NET bu işi sizin yerinizə görəcək və avtomatik olaraq uzaq proksi modelinin həyata keçirilməsini təmin edərək proksi kodu yaradacaq.
Qatlara Nümunələrin əlavə edilməsi
Üç əsas təbəqə yüksək səviyyəli icmal təmin edir. Güclü müəssisə arxitekturası yaratmaq üçün bəzi struktur nümunələri əlavə edək. Nəticə Şəkil 8-2-də göstərilmişdir.
Tətbiq məntiqi qatına diqqət yetirin. Şəkil 8-2 göstərir ki, tətbiq məntiqinə daxil olmaq fasad nümunəsindən istifadə edir. Fasad, sinif kitabxanası kimi daha böyük kod korpusuna sadələşdirilmiş interfeys təmin edən obyektdir. Fasad kitabxananın daxili işlərindən kənar kod asılılığını azalda bilər, çünki əksər kodlar fasaddan istifadə edir və beləliklə, sistemin inkişafında daha çox çevikliyə imkan verir. Bunun üçün fasad incə dənəli obyektlərin kolleksiyasına qaba dənəli interfeys təqdim edəcəkdir.
qərar axını
Qərar axını kimi də tanınan proqram axınına nəzarət tətbiq məntiqi təbəqənizdə xidmətləri necə dizayn etdiyinizə və ya əvvəlki paraqrafda gördüyünüz kimi fasadınızdakı üsulları necə tərtib etdiyinizə aiddir.
Xidmətlərinizi təşkil etmək üçün iki yanaşma var:
- fəaliyyət yönümlü
- dövlət idarə edir
Fəaliyyət yönümlü yanaşma
İstifadəçi hərəkətlərinə əsaslanan xidmətləri təşkil etməklə siz hər biri təqdimat qatından müəyyən sorğunu idarə edən xidmətlər təklif etməklə tətbiq məntiqini həyata keçirirsiniz. Bu həm də əməliyyat skripti nümunəsi kimi tanınır. Bu yanaşma sadə və çox təbii göründüyü üçün məşhurdur. Bu yanaşmaya əməl edən metodlara nümunələr BookStoreService.AddNewOrder(Sifariş sifarişi) və BookStoreService.CancelOrder(int orderId) ola bilər.
Fəaliyyəti yerinə yetirmək üçün lazım olan məntiq metod daxilində çox ardıcıl olaraq həyata keçirilir və kodu çox oxunaqlı edir, həm də təkrar istifadəni çətinləşdirir. Cədvəl modulu nümunəsi kimi əlavə dizayn nümunələrinin istifadəsi təkrar istifadəni artırmağa kömək edə bilər.
Dövlət əsaslı yanaşma
Tətbiqin qərar axınını daha çox dövlət yönümlü şəkildə həyata keçirmək də mümkündür. Tətbiq serveri tərəfindən təklif olunan xidmətlər daha ümumi xarakter daşıyır, məsələn, BookStoreService.SaveOrder(Sifariş sifarişi). Bu üsul sifarişin vəziyyətini araşdıracaq və yeni sifariş əlavə etmək və ya mövcud sifarişi ləğv etmək barədə qərar verəcək.
Məlumat strukturu layihələri
Məlumat strukturlarınızı dizayn edərkən bir neçə seçim etməlisiniz. Birinci seçim məlumatların saxlanması mexanizmi, ikincisi məlumatların məqsədli istifadəsi, üçüncüsü isə versiya tələbləridir. Məlumat strukturu dizaynlarına baxmaq üçün üç yol var:
- Xidmətlər məlumat təklif edir; data relational verilənlər bazasının əksidir.
- Məlumatlar obyektlərlə əlaqələndirilməlidir və xidmətlər obyektlərə girişi təmin edir.
- Xidmətlər tərəfindən təklif olunan məlumatlar sxemə əsaslanmalıdır.
Məlumat axını strukturunuz üçün əsas kimi üçdən birini seçmək dizayn prosesinin ilkin mərhələsində edilməlidir. Bir çox şirkətlərin bütün layihələr üzrə üç variantdan birini tələb edən şirkət təlimatı var, lakin mümkün olduqda, əldə etdiyiniz layihə üçün optimal yanaşmanı seçərək hər bir layihə üçün variantları yenidən qiymətləndirməlisiniz.
Məlumat Saxlama Mühərrikinin Seçilməsi
Tətbiqinizi tərtib edərkən, şübhəsiz ki, bir növ məlumat anbarı dizayn etməli olacaqsınız. Aşağıdakı mağazalar və məlumat saxlama formaları mövcuddur:
- Qeyd
- app.config faylı
- xml faylları
- düz mətn faylları
- Məlumat bazası
- mesaj növbəsi
Hər bir mağazanın özünəməxsus xüsusiyyətləri var və xüsusi tələblərə uyğunlaşdırıla bilər.
Məlumat axınının dizaynı
ADO.NET istifadə edərək məlumat axını
Tətbiq məntiqi qatında məlumat mərkəzli xidmətləri tətbiq etməklə siz ADO.NET-dən istifadə edərək məlumat axınınızı dizayn edəcəksiniz. .NET Framework sinif kitabxanası idarə olunan kodda verilənlərin manipulyasiyası üçün geniş tətbiq proqramlaşdırma interfeysi (API) təmin edir. ADO.NET kimi istinad edilən API System.Data ad məkanında tapıla bilər. Məlumat daşıyıcılarının və məlumat anbarlarının tam ayrılması ADO.NET-in mühüm dizayn xüsusiyyətidir. DataSet, DataTable və DataRow kimi siniflər məlumatları saxlamaq üçün nəzərdə tutulub, lakin məlumatların haradan gəldiyi barədə heç bir məlumatı yoxdur. Onlar aqnostik məlumat mənbəyi hesab olunurlar. SqlConnection, SqlDataAdapter və SqlCommand kimi ayrıca siniflər dəsti məlumat mənbəyinə qoşulmaq, məlumatların alınması və DataSet, DataTable və DataRow-un doldurulması ilə məşğul olur. Bu siniflər System.Data.Sql, System.Data.OleDB, System.Data.Oracle və s. kimi alt ad fəzalarında yerləşir. Hansı məlumat mənbəyinə qoşulmaq istədiyinizdən asılı olaraq, düzgün ad məkanında siniflərdən istifadə edə bilərsiniz və istifadə etdiyiniz məhsulun əhatə dairəsindən asılı olaraq, bu siniflərin daha çox və ya daha az funksionallıq təklif etdiyini görəcəksiniz.
DataSet məlumat mənbəyinə qoşulmadığından, proqramda məlumat axınını idarə etmək üçün kifayət qədər uğurla istifadə edilə bilər. Şəkil 8-5 bunu edərkən məlumat axınını göstərir.
Gəlin bu layihəyə nəzər salaq və təsəvvür edək ki, kimsə sizin kitab mağazanıza daxil olub və üç kitab sifariş edib. Təqdimat təbəqəsi alış-veriş səbətinin vəziyyətini idarə edirdi. Müştəri sifariş verməyə hazırdır və bütün lazımi məlumatları təqdim edir. Sifariş göndərməyi seçir. Veb səhifə bütün məlumatları biri sifariş üçün, digəri isə sifariş üçün iki Data Cədvəli olan DataSet-ə çevirir; sifariş üçün DataRow daxil edir; və sifariş xətləri üçün üç DataRows daxil edir. Veb səhifə daha sonra bu məlumatları yenidən istifadəçiyə göstərir, DataSet-ə qarşı məlumat idarəetmələrini bağlayır və soruşur: Əminsinizmi? İstifadəçi sorğunu təsdiqləyir və o, proqramın məntiqi qatına təqdim olunur. Tətbiq məntiqi təbəqəsi bütün tələb olunan sahələrin dəyərə malik olub-olmadığını yoxlamaq üçün DataSet-i yoxlayır və istifadəçinin 1000 US$-dən çox olub olmadığını yoxlamaq üçün yoxlama aparır. 00 ödənilməmiş hesablar üzrə. Hər şey qaydasındadırsa, DataSet verilənlər bazasına qoşulan və DataSet məlumatından daxiletmə bəyanatları yaradan verilənlərə giriş səviyyəsinə ötürülür.
DataSet-dən bu şəkildə istifadə proqram qurmaq və Çərçivə Sinfi Kitabxanasının gücündən və ASP.NET-in DataSet-ə qarşı GridView kimi müxtəlif idarəetmə elementlərinə məlumat bağlamaq qabiliyyətindən istifadə etmək üçün sürətli və səmərəli üsuldur. Sadə DataSet obyektlərindən istifadə etmək əvəzinə, siz Typed DataSet obyektlərindən istifadə edə və kodu təqdimat qatında, eləcə də tətbiq məntiqi qatında tətbiq etməklə kodlaşdırma təcrübəsini təkmilləşdirə bilərsiniz. Bu yanaşmanın üstünlüyü həm də yanaşmanın mənfi tərəfidir. Məlumat modelinə edilən kiçik dəyişikliklər mütləq bir çox metodun imzalarını dəyişməli olmasına səbəb olmur. Baxım baxımından bu, həqiqətən yaxşı işləyir. Təqdimat qatının mütləq istifadəçi interfeysi olmadığını xatırlayırsınızsa, o, həm də veb xidməti ola bilər. Əgər siz DataSet-in tərifini dəyişdirsəniz, ola bilsin ki, verilənlər bazasındakı sahənin adını dəyişdirirsinizsə, onda siz veb xidmətinin abunə olduğu müqaviləni dəyişdirmiş olursunuz. Təsəvvür etdiyiniz kimi, bu, bəzi əhəmiyyətli problemlərə səbəb ola bilər. Təqdimat təbəqəsi sadəcə istifadəçi interfeysidirsə, bu ssenari yaxşı işləyir, lakin xarici sistemlər və ya komponentlər üçün interfeyslər üçün siz tətbiqinizin daxili işini gizlətmək və verilənləri məlumat modelinizin birbaşa klonundan başqa bir şeyə çevirmək istəyəcəksiniz. Data Transfer Objects (DTO) yaratmaq istəyəcəksiniz.
Obyektin əlaqəli xəritələşdirilməsindən istifadə edərək məlumat axını
ADO.NET-dən istifadə edən verilənlər axını məlumat axınını idarə etmək üçün çox məlumat mərkəzli bir yanaşmadır. Məlumat və məntiq diskretdir. Spektrin digər ucu daha çox obyekt yönümlü bir yanaşma tətbiq edir. Burada verilənləri və davranışı qruplaşdırmaq üçün siniflər yaradılır. Məqsəd tətbiqin yaradıldığı biznes sahəsində tapılan məlumatları və davranışı təqlid edən sinifləri müəyyən etməkdir. Nəticə tez-tez biznes obyekti adlandırılır. Proqramı təşkil edən biznes obyektlərinin toplusu domen modeli adlanır. Bəzi tərtibatçılar zəngin bir domen modelinin daha mürəkkəb məntiq dizaynı üçün daha yaxşı olduğunu iddia edirlər. Belə bir ifadəni sübut etmək və ya təkzib etmək çətindir. Sadəcə bilin ki, seçiminiz var və bunu etmək sizə bağlıdır.
Şəkil 8-6, Şəkil 8-5-ə bənzər bir məlumat axını göstərir, indi siz obyektin relational Xəritəçəkmə qatını əlavə etdiyiniz və DataSet obyektlərini müxtəlif məlumat daşıyıcıları ilə əvəz etdiyiniz istisna olmaqla.
İndi əvvəlki kimi addım-addım edin; təsəvvür edin ki, kimsə sizin kitab mağazanıza qoşulub üç kitab sifariş edib. Təqdimat təbəqəsi alış-veriş səbətinin vəziyyətini idarə edirdi. Müştəri sifariş verməyə hazırdır və bütün lazımi məlumatları təqdim edir. Sifariş göndərməyi seçir. Veb səhifə bütün məlumatları DTO-ya çevirir, məlumatları bir sifariş üçün və üç sifariş xətti ilə saxlayır, lazım olduqda obyektləri yaradır. Veb səhifə bu məlumatları yenidən istifadəçiyə göstərir, ASP.NET 2.0-da ObjectDataSource-dan istifadə edərək DTO-ya qarşı verilənlərin bağlanmasına nəzarət edir və soruşur: Əminsinizmi? İstifadəçi seçimi təsdiqləyir və DTO tətbiqin məntiqi təbəqəsinə təqdim olunur. Tətbiq məntiqi təbəqəsi DTO-nu üç OrderLine obyektini ehtiva edən xassə ilə Order tipli biznes obyektinə çevirir. Sifariş metodu. Validate() əmri təsdiqləmək və bütün tələb olunan sahələrin dəyərə malik olduğunu yoxlamaq üçün çağırılır və istifadəçinin gözləyən sliplərdə R$ 1,000.00-dan çox olub-olmadığını müəyyən etmək üçün yoxlama aparılır. Bunun üçün sifariş Order.Customer.GetOutstandingBills() çağıracaq. Hər şey qaydasındadırsa, Order.Save() metodu çağırılır. Sorğu, sorğunun və sorğunun sətirlərinin DataSet-də Data Cədvəlinə uyğunlaşdırıldığı və DataSet verilənlər bazasına qoşulan və daxiletmə bəyanatlarını yaradan verilənlər bazasına daxilolma qatına ötürüldüyü obyektlə əlaqəli xəritələşdirmə təbəqəsindən keçəcək. DataSet-dəki məlumatlar. Əlbəttə ki, obyektlə əlaqəli xəritələşdirmənin baş verə biləcəyi bir çox yol var, lakin onların hamısı DataSet-ə çevrilməni əhatə etməyəcək. Bəziləri birbaşa daxiletmə ifadəsini yaradacaq, lakin yenə də həmin ifadəni yerinə yetirmək üçün məlumat giriş qatından istifadə edəcək.
Gördüyünüz kimi, bəzi dəyişikliklər baş verir. DTO-ların istifadəsi zəruridir, çünki biznes obyekti davranışı həyata keçirir və davranış dəyişdirilə bilər. Bu dəyişikliklərin təqdimat qatına təsirini minimuma endirmək üçün siz məlumatları biznes obyektindən çıxararaq məlumat ötürmə obyektinə çevirməlisiniz. Java-da məlumat ötürmə obyektinə çox vaxt dəyər obyekti deyilir.
Biznes obyektləri ilə işləməyin böyük üstünlüyü ondan ibarətdir ki, o, həqiqətən kodunuzu təşkil etməyə kömək edir. Mürəkkəb məntiq parçasına geri baxsanız, adətən çox oxunaqlı olur, çünki çox az santexnika kodu var. İşin mənfi tərəfi odur ki, əksər məlumat anbarları hələ də əlaqəlidir və biznes obyektlərinin əlaqəli məlumatlarla xəritələşdirilməsi olduqca mürəkkəb ola bilər.
sxemə əsaslanan xidmətlər
Məlumat axınının idarə edilməsinə gəldikdə siz indicə iki əksini gördünüz. Bir çox variasiya mümkündür. Ümumi bir variant, məlumat dəstinin məlumatların saxlanması üçün UI-nin əsas məlumat daşıyıcısı kimi istifadə edildiyi, lakin digər sistemlərdən çağırılan veb xidmətləri üçün ayrı-ayrı sxemlərin (DTO) istifadə edildiyi variantdır. Tətbiq təbəqəsi əlaqəli məlumatları əvvəlcədən təyin edilmiş sxemə çevirir. Bunun əsas üstünlüyü ondan ibarətdir ki, xidmətə istinad edən hər hansı proqram komponentin hər hansı daxili həyata keçirilməsindən asılı deyil. Bu, versiyaların tərtibində daha çox çevikliyə, interfeyslərin geriyə uyğunluğuna və xidmətin interfeysini dəyişmədən komponentin həyata keçirilməsini dəyişmək imkanı verir.
Əlbəttə ki, siz veb proqramda biznes obyektlərindən istifadə edə və DTO transformasiyasından yan keçə bilərsiniz, lakin bu, adətən yalnız proqram məntiqi veb tətbiqi ilə birlikdə həyata keçirildikdə yaxşı işləyir. Unutmayın ki, Order.Save() funksiyasına zəng etmək üçün sizə verilənlər bazası bağlantısı lazımdır. Bunun arzuolunan olub-olmaması sizə və yəqin ki, təhlükəsizlik direktorunuza bağlıdır.