დიზაინის ლოგიკის განხორციელება

განხორციელების მიდგომის ფილოსოფია

ჩანჩქერის მიდგომა

აპლიკაციის განხორციელების ჩანჩქერის მიდგომა მოითხოვს, რომ დიზაინერმა გაიაროს კონსულტაცია საბოლოო მომხმარებლის ორგანიზაციის ერთ ან მეტ წარმომადგენელთან და ჩაწეროს განაცხადის ყველა სპეციფიკაცია. როგორც წესი, სპეციფიკაციები მოდის ფუნქციური დოკუმენტების ერთობლიობაში ან გამოყენების შემთხვევაში, დაწერილი ისე, რომ საბოლოო მომხმარებელს შეეძლოს ადვილად წაიკითხოს და გაიგოს დოკუმენტები.

საბოლოო მომხმარებელი ხელს აწერს ამ დოკუმენტებს და შემდეგ დოკუმენტებს აგროვებს ტექნიკური დიზაინის ჯგუფი, რომელიც შეიმუშავებს აპლიკაციას, ქმნის სხვადასხვა არტეფაქტებს, როგორიცაა კლასის მოდელის დიაგრამები, მდგომარეობის დიაგრამები, აქტივობის დიაგრამები და მონაცემთა მოდელები. ამ ფაზის მიზანია ყველაფერი დაწეროს იმდენად დეტალურად, რომ დეველოპერს პრობლემა არ შეექმნას საჭირო კოდის შექმნას. არსებობს დიზაინის ოფიციალური გადაცემა დეველოპერულ გუნდსა და ტესტირების გუნდზე. მიწოდების შემდეგ, დეველოპერული გუნდი იწყებს კოდირებას და ტესტირების ჯგუფი იყენებს ტექნიკურ დიზაინს გამოყენების შემთხვევებთან ერთად, რათა შექმნას ტესტის შემთხვევები და ტესტის სცენარები.

მას შემდეგ, რაც დეველოპერის გუნდი დაასრულებს კოდირებას, კოდი გადაეცემა ტესტირების ჯგუფს. ტესტირების ჯგუფი ასრულებს მის მიერ შემუშავებულ ტესტებს მოთხოვნებისა და დეტალური დიზაინის საფუძველზე. ნებისმიერ პრობლემას მოაგვარებს განვითარების ჯგუფი. ტესტირებისა და გამოსწორების პროცესის დასრულების შემდეგ, განაცხადი გადაეცემა საბოლოო მომხმარებელს მიღების ტესტირებისთვის. საბოლოო მომხმარებელი ახორციელებს საბოლოო შემოწმებას, შეესაბამება თუ არა აპლიკაცია საწყის მოთხოვნებს. დამტკიცების შემთხვევაში ის ამტკიცებს მზა პროდუქტს და პროექტი სრულდება. მას შემდეგ, რაც დეველოპერის გუნდი დაასრულებს კოდირებას, კოდი გადაეცემა ტესტირების ჯგუფს.

ტესტირების ჯგუფი ასრულებს მის მიერ შემუშავებულ ტესტებს მოთხოვნებისა და დეტალური დიზაინის საფუძველზე. ნებისმიერ პრობლემას მოაგვარებს განვითარების ჯგუფი. ტესტირებისა და გამოსწორების პროცესის დასრულების შემდეგ, განაცხადი გადაეცემა საბოლოო მომხმარებელს მიღების ტესტირებისთვის. საბოლოო მომხმარებელი ახორციელებს საბოლოო შემოწმებას, შეესაბამება თუ არა აპლიკაცია საწყის მოთხოვნებს. დამტკიცების შემთხვევაში ის ამტკიცებს მზა პროდუქტს და პროექტი სრულდება. მას შემდეგ, რაც დეველოპერის გუნდი დაასრულებს კოდირებას, კოდი გადაეცემა ტესტირების ჯგუფს. ტესტირების ჯგუფი ასრულებს მის მიერ შემუშავებულ ტესტებს მოთხოვნებისა და დეტალური დიზაინის საფუძველზე.

 ნებისმიერ პრობლემას მოაგვარებს განვითარების ჯგუფი. ტესტირებისა და გამოსწორების პროცესის დასრულების შემდეგ, განაცხადი გადაეცემა საბოლოო მომხმარებელს მიღების ტესტირებისთვის. საბოლოო მომხმარებელი ახორციელებს საბოლოო შემოწმებას, შეესაბამება თუ არა აპლიკაცია საწყის მოთხოვნებს. დამტკიცების შემთხვევაში ის ამტკიცებს მზა პროდუქტს და პროექტი სრულდება.

საბოლოო მომხმარებელი ახორციელებს საბოლოო შემოწმებას, შეესაბამება თუ არა აპლიკაცია საწყის მოთხოვნებს. დამტკიცების შემთხვევაში ის ამტკიცებს მზა პროდუქტს და პროექტი სრულდება. საბოლოო მომხმარებელი ახორციელებს საბოლოო შემოწმებას, შეესაბამება თუ არა აპლიკაცია საწყის მოთხოვნებს. დამტკიცების შემთხვევაში ის ამტკიცებს მზა პროდუქტს და პროექტი სრულდება.

პროექტს შეიძლება ჰქონდეს მეტი ან ნაკლები ფაზა ჩანჩქერის მიდგომის გამოყენებისას, მაგრამ მთავარი მახასიათებელია თითოეული ფაზის ძალიან ფორმალური დასაწყისი და დასასრული, ძალიან ფორმალური მიწოდებით.

ჩანჩქერის მიდგომის უპირატესობა ის არის, რომ თითოეულ ფაზაზე პასუხისმგებელი გუნდის პასუხისმგებლობა უფრო დიდია. გასაგებია, რა უნდა მიაწოდონ, როდის უნდა მიაწოდონ და ვის უნდა მიაწოდონ. ხშირად, განვითარების გუნდს არ სჭირდება მომხმარებელთან ურთიერთობა. ეს შეიძლება იყოს ძალიან გამოსადეგი განვითარების აუთსორსინგის დროს სხვა ქვეყანაში.

ჩანჩქერის მიდგომის მთავარი მინუსი არის ის, რომ გარემოში, სადაც ყველაფერი ძალიან ფორმალურად არის ორგანიზებული, ცვლილებებზე რეაგირების მოქნილობა მცირდება. გადაადგილებაც კი ორგანიზებას საჭიროებს. როგორც ჩანს, ძალიან ცოტა კომპანია აკეთებს ამას ეფექტურად, რაც ხშირად იწვევს ზედნადების ხარჯების მნიშვნელოვან ზრდას. პროექტის ხარჯების სამართავად, ზოგიერთი კომპანია აყოვნებს მოთხოვნების ნებისმიერ ცვლილებას განაცხადის თავდაპირველ მიწოდებამდე, ფაქტობრივად აწვდის აპლიკაციას, რომელიც არ აკმაყოფილებს საბოლოო მომხმარებლის მოთხოვნებს.

სწრაფი განვითარება

მრავალი გრძელვადიანი პროგრამული უზრუნველყოფის დამუშავების პროექტი გადაჭარბებულია ბიუჯეტზე და პროდუქტის დროულად მიწოდება ვერ მოხერხდა. სწრაფი პროგრამული უზრუნველყოფის განვითარების ფილოსოფიის წინაპირობაა რისკის მინიმუმამდე შემცირება პროგრამული უზრუნველყოფის შემუშავებით მოკლე დროში ყუთებში, სახელწოდებით გამეორებები, რომლებიც, როგორც წესი, გრძელდება ერთიდან ოთხ კვირამდე. თითოეული გამეორება ჰგავს საკუთარ მინიატურულ პროგრამულ პროექტს და მოიცავს ყველა დავალებას, რომელიც აუცილებელია ახალი ფუნქციონალური ნამატის გასათავისუფლებლად: დაგეგმვა, მოთხოვნების ანალიზი, დიზაინი, კოდირება, ტესტირება და დოკუმენტაცია. მიუხედავად იმისა, რომ გამეორებამ შეიძლება არ დაამატოს საკმარისი ფუნქციონირება პროდუქტის გამოშვების გარანტიისთვის, სწრაფი პროგრამული პროექტი მიზნად ისახავს შეძლოს ახალი პროგრამული უზრუნველყოფის გამოშვება ყოველი გამეორების ბოლოს. ყოველი გამეორების ბოლოს გუნდი ხელახლა აფასებს პროექტის პრიორიტეტებს.

სწრაფი პროგრამული უზრუნველყოფის განვითარების მიზანია მომხმარებელთა კმაყოფილების მიღწევა სასარგებლო პროგრამული უზრუნველყოფის სწრაფი და უწყვეტი მიწოდებით; ყოველთვის მიზნად ისახავს შექმნას ის, რაც კლიენტს სჭირდება; მივესალმები, ვიდრე ეწინააღმდეგები, მოთხოვნების დაგვიანებულ ცვლილებებს; რეგულარულად მოერგოს ცვალებად გარემოებებს; აქვს მჭიდრო, ყოველდღიური თანამშრომლობა მეწარმეებსა და დეველოპერებს შორის, რომელშიც პირისპირ საუბარი კომუნიკაციის საუკეთესო ფორმაა.

სწრაფი პროგრამული უზრუნველყოფის განვითარების მთავარი უპირატესობა არის მოქნილობა ცვლილებებთან გამკლავებაში, ყოველთვის მიზნად ისახავს ბიზნესის საჭიროებების შესაბამისად მიწოდებას. მინუსი, რა თქმა უნდა, არის მოცულობის, დაგეგმვისა და ბიუჯეტის მართვის სირთულის ზრდა. კიდევ ერთი გავრცელებული რისკი არის შეზღუდული ყურადღება (ტექნიკურ) დოკუმენტაციაზე.

ინკრემენტული განვითარება

დამატებითი პროგრამული უზრუნველყოფის განვითარება არის სწრაფი და ჩანჩქერის განვითარების ნაზავი. აპლიკაცია შექმნილია, დანერგილია და ტესტირებულია ეტაპობრივად ისე, რომ ყოველი ნამატის მიწოდება შესაძლებელია საბოლოო მომხმარებლისთვის. პროექტი არ სრულდება ბოლო ნამატის დასრულებამდე. ის მიზნად ისახავს ჩანჩქერის შემცირებას შუალედური ნამატების განსაზღვრით და სწრაფი განვითარების ზოგიერთი უპირატესობის გამოყენებით. წინა ნამატის შესახებ მიღებული გამოხმაურების საფუძველზე, შესაძლებელია კორექტირება მორიგი ნამატის მიწოდებისას. შემდეგი მატება შეიძლება შედგებოდეს როგორც ახალი კოდისგან, ასევე ადრე მოწოდებული კოდის ცვლილებებისგან.

უპირატესობა ის არის, რომ ფორმალობა რჩება, მაგრამ ცვლილებების მართვა უფრო ადვილი ხდება. აპლიკაციის მრავალჯერ ტესტირებისა და განლაგების ღირებულება უფრო მაღალი იქნება, ვიდრე მხოლოდ ერთხელ.

პროგრამის ნაკადის კონტროლი

პროგრამის ნაკადის კონტროლის მიდგომის არჩევა ძალიან არქიტექტურული ამოცანაა. მიზანია შექმნათ თქვენი აპლიკაციის გეგმა, რომელშიც, როგორც კი დაიწყებთ ფუნქციონალურობისა და კოდის დამატებას, ყველაფერს თავისი ადგილი აქვს. თუ თქვენ ოდესმე გადახედეთ ან დაწერეთ მაღალი ხარისხის კოდი, გესმით ეს პრინციპი

საორგანიზაციო კოდი

პროგრამის ნაკადის შემუშავების პირველი ნაბიჯი არის კოდის ორგანიზება, წესების დაწესება, რომელიც დაეხმარება აპლიკაციის გეგმის, ან მონახაზის შექმნას. ტექნიკური მომსახურება, გამართვა და შეცდომების გამოსწორება უფრო მარტივად მოხდება, რადგან კოდი მდებარეობს ერთ ლოგიკურ ადგილას. მას შემდეგ რაც დაასრულებთ საფუძველს, შეგიძლიათ აირჩიოთ მიდგომა თქვენი განაცხადის ლოგიკის განსახორციელებლად.

დიზაინის შაბლონებმა მნიშვნელოვანი როლი უნდა შეასრულონ პროგრამის ნაკადის კონტროლის დიზაინში. წლების განმავლობაში, ბევრი კოდი დაიწერა და მრავალი გამოსავალი შეიქმნა განმეორებადი პრობლემებისთვის. ეს გადაწყვეტილებები ჩამოყალიბებულია დიზაინის ნიმუშებში. დიზაინის ნიმუშის გამოყენება პროგრამული უზრუნველყოფის დიზაინის საერთო პრობლემაზე დაგეხმარებათ შექმნათ გადაწყვეტილებები, რომლებიც ადვილად ამოსაცნობია და მათი დანერგვა შესაძლებელია თქვენი კოლეგების მიერ. უნიკალური პრობლემები კვლავ მოითხოვს უნიკალურ გადაწყვეტილებებს, მაგრამ თქვენ შეგიძლიათ გამოიყენოთ დიზაინის შაბლონები, რათა დაგეხმაროთ მათ გადაჭრაში.

პროექტის შექმნა

ფენები

პირველი ნაბიჯი არის ლოგიკური ფენების გათვალისწინება. გაითვალისწინეთ, რომ ფენები არ არის იგივე, რაც ფენები, ხშირად დაბნეული ან თუნდაც ერთნაირად განიხილება.

ფენები ფენების წინააღმდეგ

ფენები ეხება თქვენს კოდში საზღვრების შექმნას. ზედა ფენას შეიძლება ჰქონდეს მითითება კოდზე ქვედა ფენებში, მაგრამ ფენას არასოდეს ექნება მითითება კოდზე უფრო მაღალ ფენაში. შრეები ეხება ფენების ფიზიკურ განაწილებას მრავალ კომპიუტერზე. მაგალითად, სამსაფეხურიან აპლიკაციაში მომხმარებლის ინტერფეისი შექმნილია დესკტოპ კომპიუტერზე გასაშვებად, აპლიკაციის ლოგიკა შექმნილია აპლიკაციის სერვერზე გასაშვებად და მონაცემთა ბაზა მუშაობს მონაცემთა ბაზის სერვერზე. გამოყოფილი მონაცემთა ფენა და კოდი თითოეული ფენა შეიძლება შედგებოდეს რამდენიმე ფენისგან.

სურათი 8-1: ძირითადი სამსაფეხურიანი ორგანიზაცია

ფენები ეხება აბსტრაქციის დონეებს. 8-1-ში ნაჩვენები ფენები ჭეშმარიტია უმეტეს აპლიკაციებისთვის. ამ დონეებს ასევე მოიხსენიებენ, როგორც სამ მთავარ ფენას და შეიძლება ჰქონდეთ რამდენიმე სხვა სახელი. როგორც წესი, პრეზენტაციის ფენის კოდს შეუძლია სერვისების გამოძახება განაცხადის ლოგიკურ ფენაში, მაგრამ განაცხადის ლოგიკურმა ფენამ არ უნდა გამოიძახოს მეთოდი პრეზენტაციის ფენაში. პრეზენტაციის ფენამ არ უნდა დაურეკოს პირდაპირ მონაცემთა წვდომის ფენას, რადგან ეს გვერდის ავლით აპლიკაციის ლოგიკური ფენის მიერ განხორციელებულ პასუხისმგებლობებს. მონაცემთა წვდომის ფენა არასოდეს არ უნდა გამოიძახოს განაცხადის ლოგიკური ფენა.

ფენები მხოლოდ აბსტრაქციაა და, ალბათ, ფენების დანერგვის უმარტივესი გზაა თქვენს პროექტში საქაღალდეების შექმნა და შესაბამისი საქაღალდეში კოდის დამატება. უფრო სასარგებლო მიდგომა იქნება თითოეული ფენის განთავსება ცალკე პროექტში, რითაც შექმნით ცალკეულ შეკრებებს. თქვენი აპლიკაციის ლოგიკის ბიბლიოთეკის ასამბლეაში განთავსების უპირატესობა ის არის, რომ ის საშუალებას მოგცემთ შექმნათ ერთეული ტესტები Microsoft Visual Studio-ს ან NUnit-ის გამოყენებით, ლოგიკის შესამოწმებლად. ის ასევე ქმნის მოქნილობას თითოეული ფენის განლაგების არჩევისას.

ფიზიკური ფენები

საწარმოს აპლიკაციაში, თქვენ უნდა ელოდოთ, რომ გყავთ რამდენიმე კლიენტი იმავე ლოგიკით. სინამდვილეში, რაც აპლიკაციას საწარმოს აპლიკაციად აქცევს არის ის, რომ ის განლაგდება სამ ფენად: კლიენტი, აპლიკაციის სერვერი და მონაცემთა ბაზის სერვერი. თქვენი კომპანიის გაყიდვების დეპარტამენტის მიერ შექმნილი Microsoft Office Access აპლიკაცია, თუმცა ძალიან მნიშვნელოვანია გაყიდვების განყოფილებისთვის, არ წარმოადგენს საწარმო აპლიკაციას.

გაითვალისწინეთ, რომ განაცხადის ლოგიკა და მონაცემთა წვდომის შრეები ხშირად განლაგებულია აპლიკაციის სერვერზე. პროექტის დიზაინის ნაწილი არის არჩევა, შეხვიდეთ თუ არა აპლიკაციის სერვერზე .NET-ის ან ვებ დისტანციური სერვისების გამოყენებით. თქვენი არჩევანის მიუხედავად, თქვენ დაამატებთ კოდს, რომ ადვილად შეხვიდეთ დისტანციურ სერვისებზე პრეზენტაციის ფენაში. თუ თქვენ იყენებთ ვებ სერვისებს სერვისებზე წვდომისთვის თქვენს აპლიკაციის სერვერზე, Visual Studio .NET აკეთებს სამუშაოს თქვენთვის და წარმოქმნის პროქსი კოდს, რაც ავტომატურად უზრუნველყოფს დისტანციური პროქსის ნიმუშის განხორციელებას.

შაბლონების დამატება ფენებში

სამი ძირითადი ფენა უზრუნველყოფს მაღალი დონის მიმოხილვას. მოდით დავამატოთ რამდენიმე სტრუქტურული ნიმუში, რათა შევქმნათ ძლიერი საწარმოს არქიტექტურა. შედეგი ნაჩვენებია სურათზე 8-2.

ფოკუსირება განაცხადის ლოგიკის ფენაზე. სურათი 8-2 გვიჩვენებს, რომ აპლიკაციის ლოგიკაზე წვდომა ხდება ფასადის ნიმუშის გამოყენებით. ფასადი არის ობიექტი, რომელიც უზრუნველყოფს გამარტივებულ ინტერფეისს უფრო დიდ კოდს, როგორიცაა კლასის ბიბლიოთეკა. ფასადს შეუძლია შეამციროს გარე კოდის დამოკიდებულება ბიბლიოთეკის შიდა ფუნქციონირებაზე, რადგან კოდების უმეტესობა იყენებს ფასადს, რითაც იძლევა მეტი მოქნილობის საშუალებას სისტემის განვითარებაში. ამისათვის ფასადი უზრუნველყოფს მსხვილმარცვლოვან ინტერფეისს წვრილმარცვლოვანი ობიექტების კოლექციას.

გადაწყვეტილების ნაკადი

პროგრამის ნაკადის კონტროლი, რომელიც ასევე ცნობილია როგორც გადაწყვეტილების ნაკადი, ეხება იმას, თუ როგორ შეიმუშავებთ სერვისებს თქვენი განაცხადის ლოგიკურ ფენაში ან, როგორც წინა აბზაცში იხილეთ, როგორ ქმნით მეთოდებს თქვენს ფასადზე.

თქვენი სერვისების ორგანიზებისთვის ორი მიდგომა არსებობს:

• Მოქმედებაზე ორიენტირებული
• სახელმწიფოზე ორიენტირებული

მოქმედებაზე ორიენტირებული მიდგომა

მომხმარებლის ქმედებებზე დაფუძნებული სერვისების ორგანიზებით, თქვენ ახორციელებთ აპლიკაციის ლოგიკას სერვისების შეთავაზებით, რომელთაგან თითოეული ამუშავებს კონკრეტულ მოთხოვნას პრეზენტაციის ფენიდან. ეს ასევე ცნობილია, როგორც გარიგების სკრიპტის ნიმუში. ეს მიდგომა პოპულარულია, რადგან ის მარტივია და ძალიან ბუნებრივია. მეთოდების მაგალითები, რომლებიც მიჰყვება ამ მიდგომას, არის BookStoreService.AddNewOrder(Order order) და BookStoreService.CancelOrder(int orderId).

მოქმედების შესასრულებლად საჭირო ლოგიკა ძალიან თანმიმდევრულად ხორციელდება მეთოდის ფარგლებში, რაც ძალიან იკითხება, მაგრამ ასევე უფრო რთულია კოდის ხელახლა გამოყენება. დამატებითი დიზაინის შაბლონების გამოყენება, როგორიცაა მაგიდის მოდულის ნიმუში, დაგეხმარებათ ხელახლა გამოყენებადობის გაზრდაში.

სახელმწიფოზე ორიენტირებული მიდგომა

ასევე შესაძლებელია განაცხადის გადაწყვეტილების ნაკადის განხორციელება ბევრად უფრო სახელმწიფოზე ორიენტირებული გზით. აპლიკაციის სერვერის მიერ შემოთავაზებული სერვისები უფრო ზოგადი ხასიათისაა, მაგალითად, BookStoreService.SaveOrder(Order order). ეს მეთოდი შეხედავს შეკვეთის სტატუსს და გადაწყვეტს, დაამატოთ ახალი შეკვეთა თუ გააუქმოს არსებული შეკვეთა.

მონაცემთა სტრუქტურის პროექტები

თქვენ უნდა გააკეთოთ რამდენიმე არჩევანი თქვენი მონაცემთა სტრუქტურების შემუშავებისას. პირველი არჩევანი არის მონაცემთა შენახვის მექანიზმი, მეორე არის მონაცემთა მიზნობრივი გამოყენება და მესამე არის ვერსიების მოთხოვნები. მონაცემთა სტრუქტურის დიზაინის შეხედვის სამი გზა არსებობს:

• სერვისები გთავაზობთ მონაცემებს; მონაცემები არის რელაციური მონაცემთა ბაზის ასახვა.
• მონაცემები უნდა აისახოს ობიექტებზე და სერვისები უზრუნველყოფენ ობიექტებზე წვდომას.
• სერვისების მიერ შემოთავაზებული მონაცემები უნდა იყოს სქემაზე დაფუძნებული.

სამიდან ერთის არჩევა, როგორც თქვენი მონაცემთა ნაკადის სტრუქტურის საფუძველი, უნდა განხორციელდეს დიზაინის პროცესის ადრეულ ეტაპზე. ბევრ კომპანიას აქვს კომპანიის პოლიტიკა, რომელიც ავალდებულებს სამი ვარიანტიდან ერთ-ერთს ყველა პროექტზე, მაგრამ როდესაც ეს შესაძლებელია, თქვენ უნდა გადახედოთ თითოეული პროექტის ვარიანტებს, აირჩიოთ იდეალური მიდგომა მიმდინარე პროექტისთვის.

მონაცემთა შენახვის ძრავის არჩევა

თქვენი აპლიკაციის შექმნისას, უდავოდ მოგიწევთ მონაცემთა შენახვის გარკვეული ტიპის დიზაინი. ხელმისაწვდომია მონაცემთა შენახვის შემდეგი მაღაზიები და ფორმები:

• ჩანაწერი
• app.config ფაილი
• XML ფაილები
• უბრალო ტექსტური ფაილები
• Მონაცემთა ბაზა
• შეტყობინებების რიგი

თითოეულ მაღაზიას აქვს თავისი უნიკალური მახასიათებლები და შეიძლება მორგებული იყოს კონკრეტულ მოთხოვნებზე.

მონაცემთა ნაკადის დიზაინი

მონაცემთა ნაკადი ADO.NET-ის გამოყენებით

აპლიკაციის ლოგიკურ ფენაში მონაცემთა ორიენტირებული სერვისების დანერგვისას, თქვენ შეიმუშავებთ მონაცემთა ნაკადს ADO.NET-ის გამოყენებით. NET Framework კლასის ბიბლიოთეკა უზრუნველყოფს ფართო აპლიკაციის პროგრამირების ინტერფეისს (API) მართულ კოდში მონაცემების მანიპულირებისთვის. მოხსენიებული როგორც ADO.NET, API შეგიძლიათ იხილოთ System.Data სახელების სივრცეში. მედიისა და მონაცემთა მაღაზიების სრული გამიჯვნა არის ADO.NET-ის დიზაინის მნიშვნელოვანი მახასიათებელი. კლასები, როგორიცაა DataSet, DataTable და DataRow შექმნილია მონაცემების შესანახად, მაგრამ ისინი არ ინარჩუნებენ ცოდნას იმის შესახებ, თუ საიდან მოვიდა ეს მონაცემები. ისინი ითვლებიან მონაცემთა წყაროს აგნოსტიკებად. კლასების ცალკეული ნაკრები, როგორიცაა SqlConnection, SqlDataAdapter და SqlCommand, ზრუნავს მონაცემთა წყაროსთან დაკავშირებაზე, მონაცემების მოძიებაზე და DataSet, DataTable და DataRow-ის შევსებაზე. ეს კლასები განლაგებულია ქვესახელთა სივრცეებში, როგორიცაა System.Data.Sql, System.Data.OleDB, System.Data.Oracle და ა.შ. იმისდა მიხედვით, თუ რომელ მონაცემთა წყაროსთან გსურთ დაკავშირება, შეგიძლიათ გამოიყენოთ კლასები სწორ სახელთა სივრცეში და თქვენ მიერ გამოყენებული პროდუქტის მასშტაბიდან გამომდინარე, აღმოაჩენთ, რომ ეს კლასები მეტ-ნაკლებად ფუნქციონირებას გვთავაზობენ.

ვინაიდან DataSet არ არის დაკავშირებული მონაცემთა წყაროსთან, მისი წარმატებით გამოყენება შესაძლებელია აპლიკაციაში მონაცემთა ნაკადის სამართავად. სურათი 8-5 აჩვენებს მონაცემთა ნაკადს ამის გაკეთებისას.

მოდით, გადავხედოთ ამ პროექტს და წარმოიდგინოთ, რომ ვიღაც შემოვიდა თქვენს წიგნების მაღაზიაში და შეუკვეთა სამი წიგნი. პრეზენტაციის ფენა მართავდა კალათის მდგომარეობას. მომხმარებელი მზად არის შეკვეთის განსათავსებლად და მოწოდებული აქვს ყველა საჭირო მონაცემი. ის ირჩევს შეკვეთის გაგზავნას. ვებ გვერდი გარდაქმნის ყველა მონაცემს DataSet-ად, რომელიც შეიცავს ორ მონაცემთა ცხრილს, ერთი შეკვეთისთვის და მეორე შეკვეთისთვის; აყენებს DataRow-ს მოთხოვნისთვის; და ჩასვით სამი DataRows შეკვეთის ხაზებისთვის. შემდეგ ვებგვერდი კვლავ უჩვენებს ამ მონაცემებს მომხმარებელს, აკონტროლებს მონაცემთა დაკავშირებას DataSet-თან და ეკითხება დარწმუნებული ხართ? მომხმარებელი ადასტურებს მოთხოვნას და ის გადაეცემა აპლიკაციის ლოგიკურ ფენას. განაცხადის ლოგიკური ფენა ამოწმებს DataSet-ს, რათა ნახოს აქვს თუ არა ყველა საჭირო ველს მნიშვნელობა და ამოწმებს, აქვს თუ არა მომხმარებელს US$ 1000-ზე მეტი. 00 დაუსრულებელ გადასახადებზე. თუ ყველაფერი წესრიგშია, DataSet გადაეცემა მონაცემთა ხელმისაწვდომობის ფენას, რომელიც უკავშირდება მონაცემთა ბაზას და წარმოქმნის ჩასმის ინსტრუქციებს DataSet ინფორმაციის საფუძველზე.

DataSet-ის ამ გზით გამოყენება არის სწრაფი და ეფექტური გზა აპლიკაციის შესაქმნელად და გამოიყენოთ Framework Class Library და ASP.NET-ის უნარი, დააკავშიროს მონაცემები მრავალ კონტროლთან, როგორიცაა GridView მონაცემთა ნაკრების წინააღმდეგ. მარტივი DataSet ობიექტების გამოყენების ნაცვლად, შეგიძლიათ გამოიყენოთ Typed DataSet ობიექტები და გააუმჯობესოთ კოდირების გამოცდილება პრეზენტაციის ფენაში და ასევე აპლიკაციის ლოგიკურ ფენაში კოდის დანერგვით. ამ მიდგომის უპირატესობა ასევე არის მიდგომის მინუსი. მონაცემთა მოდელის მცირე ცვლილებები სულაც არ იწვევს ხელმოწერების შეცვლის ბევრ მეთოდს. ასე რომ, მოვლის თვალსაზრისით, ეს ძალიან კარგად მუშაობს. თუ გახსოვთ, რომ პრეზენტაციის ფენა სულაც არ არის მომხმარებლის ინტერფეისი, ის ასევე შეიძლება იყოს ვებ სერვისი. და თუ შეცვლით DataSet-ის განმარტებას, შესაძლოა იმიტომ, რომ ველს გადაარქმევთ სახელს მონაცემთა ბაზაში, მაშინ თქვენ ცვლით ხელშეკრულებას, რომელიც ითვალისწინებს ვებ სერვისი. როგორც თქვენ წარმოიდგინეთ, ამან შეიძლება გამოიწვიოს მნიშვნელოვანი პრობლემები. ეს სცენარი კარგად მუშაობს, თუ პრეზენტაციის ფენა მხოლოდ მომხმარებლის ინტერფეისია, მაგრამ გარე სისტემების ან კომპონენტების ინტერფეისებისთვის, თქვენ მოგინდებათ დამალოთ თქვენი აპლიკაციის შიდა სამუშაოები და გადააქციოთ მონაცემები სხვა რამედ, გარდა თქვენი მონაცემთა მოდელის პირდაპირ კლონად და თქვენ გსურთ შექმნათ მონაცემთა გადაცემის ობიექტები (DTO).

მონაცემთა ნაკადი ობიექტის ურთიერთობითი რუკის გამოყენებით

მონაცემთა ნაკადი ADO.NET-ის გამოყენებით არის მონაცემთა ნაკადის მართვის ძალიან მონაცემებზე ორიენტირებული მიდგომა. მონაცემები და ლოგიკა დისკრეტულია. სპექტრის მეორე მხარე უფრო ობიექტზე ორიენტირებულ მიდგომას იღებს. აქ კლასები იქმნება მონაცემთა და ქცევის დასაჯგუფებლად. მიზანია განისაზღვროს კლასები, რომლებიც მიბაძავს იმ მონაცემებსა და ქცევას, რომლებიც ნაპოვნია ბიზნეს დომენში, რომლისთვისაც შეიქმნა აპლიკაცია. შედეგს ხშირად მოიხსენიებენ, როგორც ბიზნეს ობიექტს. ბიზნეს ობიექტების კოლექციას, რომლებიც ქმნიან აპლიკაციას, ეწოდება დომენის მოდელი. ზოგიერთი დეველოპერი ამტკიცებს, რომ მდიდარი დომენის მოდელი უკეთესია უფრო რთული ლოგიკის შესაქმნელად. ასეთი განცხადების დამტკიცება ან უარყოფა რთულია. უბრალოდ იცოდე, რომ შენ გაქვს არჩევანი და შენი გადასაწყვეტია ამის გაკეთება.

სურათი 8-6 გვიჩვენებს მონაცემთა ნაკადს, რომელიც 8-5-ის მსგავსია, გარდა იმისა, რომ ახლა თქვენ დაამატეთ ობიექტურ-რელაციური რუკების ფენა და ჩაანაცვლეთ DataSet ობიექტები სხვადასხვა მონაცემთა მატარებლებით.

ახლა გააკეთეთ იგივე ეტაპობრივად, როგორც ადრე; წარმოიდგინეთ, რომ ვიღაც შევიდა თქვენს წიგნების მაღაზიაში და შეუკვეთა სამი წიგნი. პრეზენტაციის ფენა მართავდა კალათის მდგომარეობას. მომხმარებელი მზად არის შეკვეთის განსათავსებლად და მოწოდებული აქვს ყველა საჭირო მონაცემი. ის ირჩევს შეკვეთის გაგზავნას. ვებ გვერდი გარდაქმნის ყველა მონაცემს DTO-ად, ინახავს მონაცემებს ერთი შეკვეთისთვის და სამი შეკვეთის ხაზით, საჭიროების შემთხვევაში ქმნის ობიექტებს. ვებგვერდი ამ მონაცემებს კიდევ ერთხელ უჩვენებს მომხმარებელს, მონაცემთა სავალდებულო კონტროლს DTO-ს წინააღმდეგ ObjectDataSource-ის გამოყენებით ASP.NET 2.0-ში და ეკითხება დარწმუნებული ხართ? მომხმარებელი ადასტურებს არჩევანს და DTO გადაეცემა აპლიკაციის ლოგიკურ ფენას. აპლიკაციის ლოგიკური ფენა გარდაქმნის DTO-ს Order ტიპის ბიზნეს ობიექტად, თვისებით, რომელიც შეიცავს სამ OrderLine ობიექტს. შეკვეთის მეთოდი. Validate() იძახება შეკვეთის დასადასტურებლად და შესამოწმებლად აქვს თუ არა ყველა სავალდებულო ველს მნიშვნელობა, და შემოწმება ხდება იმის დასადგენად, აქვს თუ არა მომხმარებელს R$ 1,000.00-ზე მეტი ანგარიშ-ფაქტურებში. ამისათვის შეკვეთა გამოიძახებს Order.Customer.GetOutstandingBills(). თუ ყველაფერი კარგადაა, გამოიძახება Order.Save() მეთოდი. შეკვეთა გადაეცემა ობიექტის რელაციური რუკების ფენას, სადაც შეკვეთის და რიგის ხაზები აისახება DataTable-ში DataSet-ში, ხოლო DataSet გადაეცემა მონაცემთა წვდომის ფენას, რომელიც უკავშირდება მონაცემთა ბაზას და წარმოქმნის ჩასმის ინსტრუქციებს ინფორმაციისგან. მონაცემთა ნაკრები. რა თქმა უნდა, არსებობს მრავალი გზა, რომლითაც შეიძლება მოხდეს ობიექტურ-რელაციური რუკების განხორციელება, მაგრამ ყველა მათგანი არ მოიცავს მონაცემთა ნაკრებში ტრანსფორმაციას. ზოგიერთი უშუალოდ შექმნის ჩასმის განცხადებებს, მაგრამ მაინც გამოიყენებს მონაცემთა წვდომის ფენას ამ განცხადების შესასრულებლად.

როგორც ხედავთ, გარკვეული ტრანსფორმაციები ხდება. DTO-ების გამოყენება აუცილებელია, რადგან ბიზნეს ობიექტი ახორციელებს ქცევას და ქცევა ექვემდებარება ცვლილებას. ამ ცვლილებების ზემოქმედების შესამცირებლად პრეზენტაციის ფენაზე, თქვენ უნდა გადააქციოთ მონაცემები ბიზნეს ობიექტიდან და მონაცემთა გადაცემის ობიექტად. ჯავაში მონაცემთა გადაცემის ობიექტს ჩვეულებრივ უწოდებენ მნიშვნელობის ობიექტს.

ბიზნეს ობიექტებთან მუშაობის დიდი უპირატესობა ის არის, რომ ის ნამდვილად გეხმარებათ თქვენი კოდის ორგანიზებაში. თუ გადახედავთ რთული ლოგიკის ნაწილს, ის, როგორც წესი, ძალიან იკითხება, რადგან სანტექნიკის კოდი ძალიან ცოტაა. მინუსი ის არის, რომ მონაცემთა მაღაზიების უმეტესობა კვლავ ურთიერთკავშირშია და ბიზნეს ობიექტების რელაციურ მონაცემებთან დახატვა შეიძლება საკმაოდ რთული გახდეს.

სქემაზე დაფუძნებული სერვისები

თქვენ ახლახან დაინახეთ ორი საპირისპირო, როდესაც საქმე ეხება მონაცემთა ნაკადის მართვას. შესაძლებელია მრავალი ვარიაცია. გავრცელებული არის ვარიანტი, რომელშიც მონაცემთა ნაკრები გამოიყენება როგორც მომხმარებლის ინტერფეისის მონაცემთა ძირითადი მხარდაჭერა მონაცემთა შესანახად, მაგრამ ცალკეული სქემები (DTO) გამოიყენება სხვა სისტემებიდან მოწოდებული ვებ სერვისებისთვის. განაცხადის ფენა გარდაქმნის რელაციურ მონაცემებს წინასწარ განსაზღვრულ სქემაში. ამის მთავარი უპირატესობა ის არის, რომ ნებისმიერი აპლიკაცია, რომელიც მიმართავს სერვისს, არ არის დამოკიდებული კომპონენტის რაიმე სახის შიდა განხორციელებაზე. ეს იძლევა მეტი მოქნილობის შესაძლებლობას ვერსიებში, ინტერფეისების უკან თავსებადობას და კომპონენტის განხორციელების შეცვლის შესაძლებლობას სერვისის ინტერფეისის შეცვლის გარეშე.

რა თქმა უნდა, შეგიძლიათ გამოიყენოთ ბიზნეს ობიექტები ვებ აპლიკაციაში და გვერდის ავლით DTO ტრანსფორმაცია, მაგრამ ეს ჩვეულებრივ კარგად მუშაობს მხოლოდ იმ შემთხვევაში, თუ აპლიკაციის ლოგიკა განხორციელდება ვებ აპლიკაციასთან ერთად. გახსოვდეთ, რომ Order.Save(-ს) გამოძახებისთვის დაგჭირდებათ მონაცემთა ბაზის კავშირი. სასურველია თუ არა ეს თქვენ და ალბათ თქვენი უსაფრთხოების დირექტორის გადასაწყვეტია.