კონტროლირებადი ფორმების uv 1s აღწერა. StavAnalit

ჩვენ ყველამ ვიცით, რომ 1C კომპანიას ჰქონდა 1C პლატფორმის მრავალი განსხვავებული ვერსია; ახლა ჩვენ დავინტერესდებით ამ სტატიის დაწერის დროს ერთ-ერთი უახლესი ვერსიით, ეს არის ვერსიები 1C 8.2 და 1C 8.3. თუ თქვენ მოგიწიათ მუშაობა ორივე ამ ვერსიაში, მაშინ დიდი ალბათობით შენიშნა განსხვავებები ამ ვერსიების ინტერფეისებში, მომხმარებლებისთვის ისინი განსხვავდებიან მხოლოდ გარეგნულად. არსებითად არჩევანი რეგულარული ან მართული აპლიკაციაეუბნება სისტემას რომელი ფორმების ჩვენება გასაშვებად, რეგულარული ან კონტროლირებადი, ასევე, რომელი აპლიკაციის კლიენტი იქნება გამოყენებული ნაგულისხმევად, სქელი თუ თხელი. კლიენტების შესახებ უფრო დეტალური ინფორმაციისთვის წაიკითხეთ სტატია „რა არის სქელი და გამხდარი კლიენტები 1C-ში, ასევე მათი განსხვავებები“.

რეგულარული 1C აპლიკაცია (რეგულარული ფორმები, რეგულარული ინტერფეისი, ვერსია 1C 8.2)

1C 8.2-ში შესაძლებელია მხოლოდ მუშაობა რეგულარული ფორმებით, რეგულარული განაცხადის რეჟიმში. ქვემოთ მოყვანილი სურათი გვიჩვენებს მონაცემთა ბაზას „ჩვეულებრივი 1C აპლიკაციის“ ოპერაციულ რეჟიმში (ჩვეულებრივი ფორმები).

მართული 1C აპლიკაცია (მართული ფორმები, მართული ინტერფეისი, ვერსია 1C 8.3)

1C 8.3 პლატფორმაზე ჩვენ შეგვიძლია ვიმუშაოთ როგორც ჩვეულებრივ ფორმებთან (თავსებადობის რეჟიმში) ასევე მართულ ფორმებთან. მეტიც მართულ ფორმებს აქვს ორი ტიპის ჩვენება, ეს არის სტანდარტული და ტაქსი. 1C 8.3 კონფიგურაციის მაგალითი სტანდარტული მართული ფორმებით ნაჩვენებია ქვემოთ, შემდეგ კი ნაჩვენებია "ტაქსი" ინტერფეისი.

რა განსხვავებაა ჩვეულებრივ და მართულ 1C აპლიკაციას შორის?

როგორც უკვე გავარკვიეთ ჩვეულებრივი აპლიკაცია და მართული აპლიკაცია არის 1C პროგრამის გაშვების ეს ტიპები. უფრო მეტიც, 1C გაშვების ტიპის მნიშვნელობიდან გამომდინარე ( რეგულარული ან მართული აპლიკაცია), სტანდარტულად ჩაიტვირთება კონკრეტული ინტერფეისი ( რეგულარული ან მართული ფორმები), ამიტომ ამ კონცეფციის ამდენი სინონიმია. ჩვენ გვინდა აღვნიშნოთ, რომ განსხვავებები ინტერფეისებში საკმაოდ მნიშვნელოვანია; მართული ინტერფეისი მთლიანად შეიცვალა. პრინციპში, ეს არის ყველა განსხვავება, რომელსაც ხედავენ 1C პროგრამის რიგითი მომხმარებლები. რაც შეეხება პროგრამისტებს, მართული ინტერფეისი მოითხოვს შეცვლილი კოდის დაწერას, რადგან განვითარება უკვე ხორციელდება 1C 8.3-ში, და არა 1C 8.2-ში, შესაბამისად, ყველა შემდგომი შედეგი. კოდი ასევე უნდა დაიყოს კლიენტად და სერვერად; ეს მითითებულია კონფიგურატორში შესაბამისი დირექტივების გამოყენებით.

1C Enterprise 8.2 პლატფორმის მოსვლასთან ერთად, მომხმარებლის ინტერფეისის განვითარების მექანიზმი მნიშვნელოვნად შეიცვალა. შესაძლებელი გახდა მართული ფორმებისა და აპლიკაციების შექმნა (სურათი 1).

სურათი 1

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

  • სქელი კლიენტი (ნორმალური და მართული გაშვების რეჟიმი),
  • თხელი კლიენტი,
  • ვებ კლიენტი.

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

  • &OnClient,
  • &სერვერზე,
  • &სერვერზე კონტექსტის გარეშე,
  • &OnClientOnServerWithoutContext.

მართული ფორმა ასევე განსხვავდება ჩვეულებრივი ფორმისგან იმ მონაცემებით, რომლებთანაც მუშაობს. თუ ნორმალური ფორმა მუშაობს უმეტეს ტიპებთან, რომლებსაც გთავაზობთ 1C: Enterprise (მათ შორის, ტიპები DirectoryObject, DocumentObject და ა.შ.), მაშინ მართულ ფორმაში შეიძლება გამოიყოს შემდეგი ტიპის ტიპები:

  • ტიპები, რომლებიც პირდაპირ გამოიყენება ფორმაში, არის ის ტიპები, რომლებიც არსებობს თხელი და ვებ კლიენტის მხარეს (მაგალითად, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • ტიპები, რომლებიც გარდაიქმნება მონაცემთა სპეციალურ ტიპებად - მართული ფორმის მონაცემთა ტიპებად. ასეთი ტიპები ნაჩვენებია ფორმის დეტალების სიაში ფრჩხილებში, მაგალითად (DirectoryObject.Products);
  • დინამიური სია.

კონტროლირებადი ფორმების ფუნქციონირებას აქვს შემდეგი გამორჩეული მახასიათებლები (სურათი 2):

  • ფორმა არსებობს როგორც კლიენტზე, ასევე სერვერზე.

იგი ახორციელებს კლიენტ-სერვერის ურთიერთქმედებას (მონაცემების გადაცემა და ელემენტების დიზაინის თვისებები).

  • ფორმა არ მუშაობს აპლიკაციის ობიექტებთან


სურათი 2

ფორმა იყენებს სპეციალურ უნივერსალურ ობიექტებს
DataForms(სურათი 3).


სურათი 3

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

  • ობიექტი იკითხება მონაცემთა ბაზიდან,
  • ობიექტი გარდაიქმნება ფორმის მონაცემად,
  • ობიექტი ამოღებულია (მეხსიერებიდან),
  • ფორმის მონაცემები ეგზავნება კლიენტს.

ჩაწერისას:

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

ვთქვათ, არსებობს გარე დამუშავება დაწერილი 8.1 ვერსიისთვის. შესაძლებელია თუ არა მისი გაშვება 8.2-ში ისე, რომ იმუშაოს თავისი ძველი, უმართავი ფორმით? დამუშავება საჭიროა მხოლოდ ერთხელ, მონაცემების გადასატანად და არ გსურთ შექმნათ მართული ფორმა მხოლოდ ერთხელ...

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

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

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

უმარტივესი გზაა სქელი კლიენტის გაშვება მართული აპლიკაციის რეჟიმში კონფიგურატორიდან, ამის მითითებით პარამეტრებში: სერვისი - ოფციები - გაშვება 1C: Enterprise - ძირითადი - სქელი კლიენტი (მართული აპლიკაცია).

თუმცა, უნდა გახსოვდეთ, რომ კლიენტების მართულ რეჟიმში გაშვება შესაძლებელია მხოლოდ იმ შემთხვევაში, თუ კონფიგურაციას აქვს 8.1 ვერსიის თავსებადობა გამორთული (თვისება თავსებადობის რეჟიმი).

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

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

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

და ბოლოს, ობიექტს, რომლის ნორმალური ფორმის ნახვა გსურთ მართულ რეჟიმში, უნდა ჰქონდეს ერთი მთავარი ობიექტის ფორმა და ეს ფორმა უნდა იყოს ნორმალური, უმართავი.

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

მთავარი პრობლემა ის არის, რომ 10-15 წელზე მეტი ხნის განმავლობაში უკვე შედგენილია უამრავი კოდი ჩვეულებრივი ფორმებისთვის. არავის სურს ამ ყველაფრის გადაწერა კლიენტ-სერვერზე + ბევრი ადამიანია გაწვრთნილი ინტერფეისით მუშაობისთვის. მომავალი წლიდან დაწყებული BP 3.0-ზე სავალდებულო გადასვლა პანიკას ქმნის დეველოპერებისა და ბუღალტერების გონებაში. გამოხმაურება ძალიან უსიამოვნო იქნება. გარდა ამისა, პროფესიაში შესვლის ბარი იწევს, პროგრამირება უფრო რთულია, სტანდარტული კი კიდევ უფრო რთული. რა ღირს ახალი ალგორითმი სტანდარტულ დოკუმენტებში? UV მშვენივრად გამოიყურება, როდესაც დოკუმენტებზე გაქვთ 2-3 ღილაკი, UV შესანიშნავია მობილურ მოწყობილობებზე მუშაობისთვის, მაგრამ კომპანიების მხოლოდ 0.01% იყენებს მას. თქვენ მოგიწევთ გადართვა, თუ 1C არ მოიფიქრებს რაიმე ახალს, მაგრამ ეს იქნება ხანგრძლივი და მტკივნეული ყველასთვის. თანხის გადახდა კი კომპანიებს თავად მოუწევთ.

მეც მხოლოდ ნეგატიური განვიცადე კონტროლირებადი ფორმებიდან, აქ არის ინოვაციის კიდევ რამდენიმე უარყოფითი მხარე:

  • არაფერი? ხო, ამას რამდენჯერმე შევხვდი, მაგალითად, გარე ბეჭდვის ფორმის დაწერა და მიმაგრება ZUP conf-ზე, იქ დამუშავება არის მთელი ეპოსი, სავსე ინსტრუქციებით ინტერნეტში და გვერდებზე კოდი უნდა.
    სქელ კლიენტზე არის ერთი პროცედურა პარამეტრებით ე.ი. განვითარება წუთების საკითხია.
    და მუხრუჭები თხელია შეუიარაღებელი თვალით
  • რაც შეეხება მართვადი ფორმების მომზადების შესაძლებლობას - ეს არის ხელოვნება ხელოვნებისთვის, მაგრამ რა არის პრაქტიკული აზრი, განსაკუთრებით ფაილური ვერსიისთვის?
  • 3 წელი ვძერწავდი ულტრაიისფერში, მაგრამ ახლა ისევ მარტივ ფორმებს დავუბრუნდი და დამიჯერეთ, ფსიქოლოგიურად საკმაოდ რთული იყო ეს გადასვლა, მაგრამ ეს ჩემი შეგნებული არჩევანია, რადგან ის, რასაც 1c გვთავაზობს UV-ში, არის სრულიად UG…. შესაძლოა რამდენიმე წელიწადში 1c მიაღწიოს გარღვევას, მაგრამ ახლა ის უბრალოდ ეძებს ადგილს, სადაც ეს გარღვევა...
  • კონფიგურატორში ულტრაიისფერი სხივების გახსნას გაცილებით მეტი დრო სჭირდება.
    ამის შემდეგ 8.1-ში ფორმების გახსნა სატვირთო მანქანიდან თვითმფრინავში გადაყვანას ჰგავს!
  • ყველასთვის მეტი პრობლემაა, მომხმარებლები შოკირებულია ახალი ინტერფეისით (ყველა არ აღიარებს ამას, მაგრამ ისინი ბევრად უფრო სულელები არიან წვრილმანებზე), პროგრამისტების ნახევარი გახდა შეუფერებელი პროფესიონალიზმისთვის, უფრო რთული გახდა საშუალო სპეციალისტისთვის. იპოვნეთ სამუშაო და როგორ აწარმოოთ ხარისხიანი პროდუქტი. და UV-ის ყველაზე მაგარი მარკეტინგული თემა არის ის, რომ ისინი ყველგან იმატებენ, რომ გადასვლა ხდება მარტივი განახლებით, მაგრამ ყველას ავიწყდება, რომ თავიდანვე უნდა დაეწიოთ უახლეს გამოშვებებს! მაგრამ პრინციპში მომწონს იდეა!
  • არ ვიცი, ჩემი გამოცდილება საპირისპიროს აჩვენებს. სადაც მკაცრი ფორმების ბუმები უკვე რამდენიმე წელია ავტომატურად ხვდება, ახალ UV სტანდარტებში ყოველთვიურად იწყება „რატომ, სად არის ახლა 1C ამ ღილაკის განახლების შემდეგ და რატომ არ მუშაობს ახლა“, რაც, ხედავთ. , არ მატებს სიჩქარეს.
  • - მეტი კოდია
    - კოდი უფრო რთული გახდა
    — სტანდარტულების მოდიფიკაცია გაცილებით რთულია
    - მომხმარებლებმა, რომლებსაც მე მივეცი UT11, ვერ იპოვეს რაიმე უპირატესობა 10.x-თან შედარებით
    — მაგრამ მათ აღმოაჩინეს გარკვეული შენელება და ისეთი ფუნქციების ნაკლებობა, როგორიცაა ძებნა (რატომღაც მათ სურდათ წინ-უკან ძიება და არა შერჩევა)
    ჩემი აზრით, მსხვერპლი ძალიან დიდია ვებ კლიენტისა და ტაბლეტების გულისთვის. უფრო მეტიც, პირადად მე ჯერ არ მინახავს რეალური მუშაობა ვებ კლიენტთან, რომელსაც უნდა წარმატებით გამოიყენოს დისტანციური წვდომა
  • Client-Server bedlam უნდა უზრუნველყოფდეს შესრულებისა და მასშტაბურობის გაზრდას, ხოლო ამავე დროს ხარჯები მოიცავს კოდირების ზრდას.
    თუმცა, ყველას არ განუცდია ზრდა, შესაბამისად იმედგაცრუება. და ამავდროულად, ყველას ეხებოდა კოდირების ხარჯები.
    P.S. ფაქტობრივად, კონტროლირებადი მომწონს, მშვიდად ვხატავ მათზე. მაგრამ ტიპიური პირობა გარყვნილი გახდა.
  • სახლში (ჩვეულებრივი კომპიუტერი) სასმელს ვატარებ ინდივიდუალური მეწარმეების მიხედვით.
    8.3, BP3, ჩექმიანი. მთავარი შთაბეჭდილება ისეთია, რომ არ ვმუშაობ, მაგრამ სულ ველოდები. ჰემოროიდული რეაქცია. SALT ანგარიშისთვის უბრალოდ გასაოცრად ყალიბდება - როგორც ჩანს, წლის ანგარიშის ბარათს მეგაჰოლდინგში.
  • UT11 არის ველური სამუხრუჭე, საშინელება და ზოგადად კოშმარი.
    UT10 დაფრინავს UT11-თან შედარებით.
    რაც შეეხება ულტრაიისფერ სხივებს, წლებია, რაც აწუხებს, ყველაფერი დახრილია, სვეტები არასდროს ჯდება ერთ ეკრანზე, დაჭიმვა ხშირ შემთხვევაში საშინელებაა.
    და კიდევ შემიძლია ჩამოვთვალო ბევრი მინუსი, მაგრამ პლიუსებზე ალბათ არაფერს ვიტყვი. ისინი უბრალოდ არ არსებობენ.
    ფირმებმა კონკრეტულად დაასრულეს ეს ფორმები, რადგან განვითარება უფრო ძვირია, არ იყო სპეციალური და არ არის ნორმალური.

უპირატესობები ცოტაა, მაგრამ რა თქმა უნდა არსებობს...

დადებითი:

პასუხი დიდი ხანია არსებობს, რა გასცა UP:

ჯვარედინი პლატფორმის კლიენტი

  • ცუდი საკომუნიკაციო ხაზებზე მუშაობა
  • ბრაუზერის საშუალებით მუშაობის უნარი (კლიენტის ინსტალაციის გარეშე)

და მონაცემთა გადაცემის ობიექტი კოდის სტრუქტურირებაზე, კონტროლირებადი ფორმით 1C 8.2 გარემოში.

შესავალი

დავიწყოთ „მართული ფორმის“ კონცეფციისა და 1C პლატფორმის მასთან დაკავშირებული ცნებების მოკლე აღწერით. პლატფორმის მცოდნეებმა შეიძლება მოისურვონ ამ განყოფილების გამოტოვება.

2008 წელს ხელმისაწვდომი გახდა 1C პლატფორმის ახალი ვერსია: Enterprise 8.2 (შემდგომში მართული აპლიკაცია), რომელიც მთლიანად ცვლის ინტერფეისთან მუშაობის მთელ ფენას. ეს მოიცავს ბრძანების ინტერფეისს, ფორმებს და ფანჯრის სისტემას. ამავდროულად, არა მხოლოდ იცვლება მომხმარებლის ინტერფეისის შემუშავების მოდელი კონფიგურაციაში, არამედ შემოთავაზებულია ახალი არქიტექტურა კლიენტის აპლიკაციასა და სერვერს შორის ფუნქციონირების გამიჯვნისთვის.
მართული აპლიკაცია მხარს უჭერს შემდეგი ტიპის კლიენტებს:

  • სქელი კლიენტი (ნორმალური და მართული გაშვების რეჟიმი)
  • გამხდარი კლიენტი
  • ვებ კლიენტი
მართული აპლიკაცია იყენებს ახალ ტექნოლოგიაზე აგებულ ფორმებს. მათ ეძახიან მართული ფორმები. გადასვლის შემსუბუქების მიზნით, წინა ფორმებიც (ე.წ. Regular ფორმები) არის მხარდაჭერილი, მაგრამ მათი ფუნქციონირება არ არის განვითარებული და ისინი ხელმისაწვდომია მხოლოდ სქელი კლიენტის გაშვების რეჟიმში.
დეველოპერისთვის მართული ფორმების ძირითადი განსხვავებები:
  • სტრუქტურის დეკლარაციული და არა „პიქსელ-პიქსელი“ აღწერა. ელემენტების სპეციფიკური განლაგება ხდება სისტემის მიერ ავტომატურად, როდესაც ფორმა გამოჩნდება.
  • ფორმის ყველა ფუნქცია აღწერილია როგორც დეტალებიდა გუნდები. დეტალები არის მონაცემები, რომლებთანაც მუშაობს ფორმა, ხოლო ბრძანებები არის შესასრულებელი მოქმედებები.
  • ფორმა მუშაობს როგორც სერვერზე, ასევე კლიენტზე.
  • კლიენტის კონტექსტში, აპლიკაციის თითქმის ყველა ტიპი მიუწვდომელია და, შესაბამისად, შეუძლებელია ინფორმაციის შეცვლა მონაცემთა ბაზაში.
  • თითოეული მეთოდის ან ფორმის ცვლადისთვის ის უნდა იყოს მითითებული შედგენის დირექტივა, შესრულების ადგილმდებარეობის (კლიენტი ან სერვერის) განსაზღვრა და ფორმის კონტექსტზე წვდომა.
მოდით ჩამოვთვალოთ ფორმის მეთოდების შედგენის დირექტივები:
  • &OnClient
  • &სერვერზე
  • &სერვერზე კონტექსტის გარეშე
  • &OnClientOnServer კონტექსტის გარეშე
მოდით ილუსტრაციით აღვნიშნოთ ზემოთ. სკრინშოტი აჩვენებს მართული ფორმისა და მისი მოდულის მაგალითს განვითარების რეჟიმში. იპოვნეთ დეკლარაციული აღწერა, რეკვიზიტები, კომპილაციის დირექტივები და ა.შ.

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

მოდით განვსაზღვროთ პრობლემა

რამდენიმე წელი გავიდა მას შემდეგ, რაც 1C პლატფორმის ახალი ვერსია აქტიურად გამოიყენება და მრავალი გადაწყვეტა (კონფიგურაცია) გამოვიდა როგორც 1C-ის, ისე მისი მრავალი პარტნიორის მიერ.
ამ დროის განმავლობაში, შეიმუშავეს თუ არა დეველოპერებმა ფორმების შექმნისას კლიენტ-სერვერის ურთიერთქმედების პრინციპების საერთო გაგება და შეიცვალა თუ არა მიდგომა პროგრამული მოდულების დანერგვისადმი ახალ არქიტექტურულ რეალობაში?

მოდით შევხედოთ კოდის სტრუქტურას (ფორმის მოდულს) იმავე სტანდარტული კონფიგურაციის რამდენიმე ფორმით და შევეცადოთ იპოვოთ შაბლონები.
სტრუქტურის მიხედვით ჩვენ ვგულისხმობთ კოდის სექციებს (ყველაზე ხშირად ეს არის კომენტარების ბლოკები), რომლებიც გამოყოფილია დეველოპერის მიერ ამ მეთოდების მეთოდებისა და კომპილაციის დირექტივების დასაჯგუფებლად.
მაგალითი 1:
მოვლენის დამმუშავებლების განყოფილება მეთოდი - კლიენტზე მეთოდი - სერვერზე მეთოდი - კლიენტზე მომსახურების პროცედურების და ფუნქციების განყოფილება შეყვანის დამხმარე კონტროლის ფუნქციები
მაგალითი 2:
მომსახურების პროცედურები და ფუნქციები გადახდის დოკუმენტები ღირებულებები Event handlers
მაგალითი 3:
სერვისის პროცედურები სერვერზე მომსახურების პროცედურები კლიენტზე სერვისის პროცედურები სერვერზე კონტექსტის გარეშე Header event handlers ბრძანების ღონისძიების დამმუშავებლები
მაგალითი 4:
ზოგადი დანიშნულების პროცედურები ფორმა მოვლენის დამმუშავებლები „საკონტაქტო ინფორმაციის“ ქვესისტემის პროცედურები
არსებითად, კოდის სტრუქტურა აკლია, ან რბილად რომ ვთქვათ, ის მსგავსია 8.1 ფორმებში:

  • არაინფორმაციული სიტყვები „გენერალი, სამსახური, დამხმარე“.
  • მორცხვი მცდელობა კლიენტისა და სერვერის მეთოდების გამიჯვნას.
  • მეთოდები ხშირად ჯგუფდება ინტერფეისის ელემენტების მიხედვით „მუშაობა ტაბულურ ნაწილთან პროდუქტები, საკონტაქტო ინფორმაცია“.
  • მეთოდებისა და კოდების ჯგუფების თვითნებური მოწყობა. მაგალითად, Event Handlers შეიძლება იყოს ზემოთ ერთი ფორმით, ბოლოში მეორეში, საერთოდ არ იყოს მონიშნული მესამეში და ა.შ.
  • და არ უნდა დაგვავიწყდეს, რომ ეს ყველაფერი ერთ კონფიგურაციაშია.
  • დიახ, არის კონფიგურაციები, რომლებშიც სიტყვები "გენერალი, სერვისი, დამხმარე" ყოველთვის ერთსა და იმავე ადგილებშია, მაგრამ...
რატომ გჭირდებათ კოდის სტრუქტურა?
  • მოვლის გამარტივება.
  • სწავლის გამარტივება.
  • ზოგადი/მნიშვნელოვანი/წარმატებული პრინციპების ჩაწერა.
  • ... თქვენი ვარიანტი
რატომ არ ეხმარება განვითარების არსებული სტანდარტი 1C-დან?
მოდით გადავხედოთ ITS დისკებზე და სხვადასხვა „დეველოპერთა სახელმძღვანელოში...“ გამოქვეყნებულ პრინციპებს, რომლებიც რეკომენდებულია მართული ფორმის დაწერისას.
  • შეამცირეთ სერვერის ზარების რაოდენობა.
  • მაქსიმალური გამოთვლა სერვერზე.
  • არაკონტექსტუალური სერვერის ზარები უფრო სწრაფია, ვიდრე კონტექსტუალური.
  • პროგრამა კლიენტ-სერვერის კომუნიკაციის გათვალისწინებით.
  • და ასე შემდეგ.
ეს არის სლოგანები, რომლებიც აბსოლუტურად მართალია, მაგრამ როგორ განვახორციელოთ ისინი? როგორ შევამციროთ ზარების რაოდენობა, რას ნიშნავს კლიენტ-სერვერის რეჟიმში დაპროგრამება?

დიზაინის ნიმუშები ან თაობის სიბრძნე

კლიენტ-სერვერის ურთიერთქმედება ათწლეულების განმავლობაში გამოიყენება სხვადასხვა პროგრამულ ტექნოლოგიებში. წინა ნაწილში გაწერილ კითხვებზე პასუხი დიდი ხანია ცნობილია და შეჯამებულია ორ ძირითად პრინციპში.
  • დისტანციური ფასადი(შემდგომში მოხსენიებული, როგორც დისტანციური წვდომის ინტერფეისი)
  • მონაცემთა გადაცემის ობიექტი(შემდგომში მონაცემთა გადაცემის ობიექტი)
სიტყვა მარტინ ფაულერისგან, მისი აღწერა ამ პრინციპების შესახებ:
  • … თითოეულ ობიექტს, რომელიც პოტენციურად არის განკუთვნილი დისტანციური წვდომისთვის, უნდა ჰქონდეს დაბალი მარცვლოვნების ინტერფეისი, რაც მინიმუმამდე დააყენებს გარკვეული პროცედურის შესასრულებლად საჭირო ზარების რაოდენობას. ... ინვოისისა და მისი ყველა ნივთის ცალკე მოთხოვნის ნაცვლად, თქვენ უნდა წაიკითხოთ და განაახლოთ ყველა ინვოისის ელემენტი ერთ მოთხოვნაში. ეს გავლენას ახდენს ობიექტის მთელ სტრუქტურაზე... გახსოვდეთ: დისტანციური წვდომის ინტერფეისი არ შეიცავს დომენის ლოგიკას.
  • ...მზრუნველი დედა რომ ვიყო, აუცილებლად ვეტყოდი ჩემს შვილს: „არასოდეს დაწერო მონაცემთა გადაცემის ობიექტები!“ უმეტეს შემთხვევაში, მონაცემთა გადაცემის ობიექტები სხვა არაფერია გაბერილი ველის ნაკრები... ამ ამაზრზენი მონსტრის ღირებულება მხოლოდ შესაძლებლობაშია გადასცეს მრავალი ინფორმაცია ქსელში ერთი ზარით- ტექნიკა, რომელსაც დიდი მნიშვნელობა აქვს განაწილებული სისტემებისთვის.
შაბლონების მაგალითები 1C პლატფორმაზე
აპლიკაციის პროგრამირების ინტერფეისი, რომელიც ხელმისაწვდომია დეველოპერისთვის მართული ფორმის შემუშავებისას, შეიცავს ამ პრინციპების მრავალ მაგალითს.
მაგალითად, OpenForm() მეთოდი, ტიპიური "უხეში" ინტერფეისი.
OpeningParameters = ახალი სტრუქტურა ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form = OpenForm(FormName, OpeningParameters);
შეადარე 8.1-ში მიღებულ სტილს.
ფორმა = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

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

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
სისტემის მონაცემთა გადაცემის ობიექტების გადაქცევა აპლიკაციის ტიპებად და პირიქით, ხორციელდება შემდეგი მეთოდების გამოყენებით:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
ხშირად აშკარა კონვერტაცია გამოიყენება არსებული გადაწყვეტის ადაპტაციისას. მეთოდებმა შეიძლება მოელოდეს (ფუნქციების გამოყენება) შეყვანის პარამეტრებს, როგორიცაა ValueTable და არა FormDataCollection, ან მეთოდი განისაზღვრა აპლიკაციის ობიექტის კონტექსტში და მიუწვდომელი გახდა ფორმიდან პირდაპირი გამოძახებისთვის.
მაგალითი 1C v8.1:
// კლიენტზე FillUserCache(DepartmentLink) ფორმის კონტექსტში
მაგალითი 1C v8.2:
// სერვერზე ფორმის კონტექსტში ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

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

  • პრიმიტიული ტიპები (სტრიქონი, რიცხვი, ლოგიკური)
  • სტრუქტურა
  • მიმოწერა
  • მასივი
  • აპლიკაციის ობიექტებთან ბმულები (უნიკალური იდენტიფიკატორი და ტექსტის წარმოდგენა)
მაგალითი: მეთოდი იღებს შეკვეთების ჩამონათვალს სტატუსის შესაცვლელად და უბრუნებს კლიენტს შეცდომების აღწერას.
&OnServerWithoutContext ფუნქცია ServerChangeOrderStatus(Orders, NewStatus) შეცდომები = New Match(); // [ბრძანება][შეცდომის აღწერა] ყოველი შეკვეთისთვის Orders From Orders Cycle StartTransaction(); სცადეთ DocOb = Order.GetObject(); …. სხვა ქმედებები, შესაძლებელია არა მხოლოდ შეკვეთით... გამონაკლისი CancelTransaction(); Errors.Insert(Order, ErrorDescription()); ბოლო მცდელობა; საბოლოო ციკლი; დაბრუნების შეცდომა; EndFunction // ServerChangeOrderStatus()

კოდის სტრუქტურირება

ძირითადი მიზნები, რომლებიც უნდა ასახავდეს მართული ფორმის მოდულს და მიდგომას გადაწყვეტისკენ.
  • კლიენტისა და სერვერის კოდის ნათელი გამიჯვნა.არ უნდა დაგვავიწყდეს, რომ შესრულების დროს ეს არის ორი ურთიერთდაკავშირებული პროცესი, რომელთაგან თითოეულს აქვს მნიშვნელოვნად განსხვავებული ხელმისაწვდომი ფუნქციონირება.
  • დისტანციური წვდომის ინტერფეისის მკაფიო იდენტიფიკაცია, რომელი სერვერის მეთოდების გამოძახება შეიძლება კლიენტისგან და რომელი არა? დისტანციური ინტერფეისის მეთოდების სახელები იწყება პრეფიქსით "სერვერი". ეს საშუალებას გაძლევთ დაუყოვნებლივ ნახოთ სერვერზე კონტროლის გადაცემა კოდის წაკითხვისას და ამარტივებს კონტექსტური დახმარების გამოყენებას. გაითვალისწინეთ, რომ ოფიციალური რეკომენდაცია (ITS) გვთავაზობს მეთოდების დასახელებას პოსტფიქსებით, მაგალითად, ChangeOrderStatusOnServer(). თუმცა, ვიმეორებთ, რომ სერვერის ყველა მეთოდის გამოძახება შეუძლებელია კლიენტისგან და, შესაბამისად, ლოგიკური ხელმისაწვდომობა უფრო მნიშვნელოვანია, ვიდრე კომპილაციის მდებარეობა. ამიტომ, პრეფიქსით „სერვერი“ ჩვენ აღვნიშნავთ მხოლოდ კლიენტისთვის ხელმისაწვდომ მეთოდებს; მოდით ვუწოდოთ მაგალითი მეთოდი ServerChangeOrderStatus().
  • კითხვადობა.გემოვნების საკითხია, ჩვენ ვიღებთ შეკვეთას, როდესაც მოდული იწყება სერვერზე ფორმის შექმნის პროცედურებით და დისტანციური წვდომის მეთოდებით.
  • შენარჩუნებაუნარიანობა.უნდა არსებობდეს მკაფიო მდებარეობა ახალი კოდის დასამატებლად. მნიშვნელოვანი ისაა, რომ კონფიგურატორის მიერ ავტომატურად შექმნილი მეთოდის შაბლონები ემატება მოდულის ბოლოს. ვინაიდან ფორმის ელემენტების მოვლენების დამმუშავებლები ყველაზე ხშირად ავტომატურად იქმნება, შესაბამისი ბლოკი განლაგებულია ბოლოს ისე, რომ არ გადაიტანოთ თითოეული დამმუშავებელი მოდულის სხვა ადგილას.
ქვემოთ მოცემულია მოდულის ძირითადი სტრუქტურა, რომელიც ახორციელებს ჩამოთვლილ მიზნებს.
  • გრაფიკული ვარიანტი - ნათლად აჩვენებს შესრულების ძირითად ნაკადს.
  • ტექსტის ვარიანტი არის შაბლონის დიზაინის მაგალითი სტრუქტურის ახალი ფორმის მოდულში სწრაფად ჩასართავად.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""თარიღი = ""/> // <Описание> // // //////////////////////////////////////////// ///////////////////////// // მოდულის ცვლადები ////////////////// /////////////////////////////////////////////////////////////////////// ////////// // სერვერზე //******** მოვლენები სერვერზე ******* &სერვერის პროცედურები სერვერზე შექმნისას (მარცხი, სტანდარტული დამუშავება) / /დასვით დამმუშავებლის შიგთავსი პროცედურის დასასრული //******** დისტანციური წვდომის ინტერფეისი ******* //******** BUSINESS LOGIC სერვერზე ******* ///////// ///////////////////////////////////////////////////////// /////// /////////////////// // კლიენტისა და სერვერის საერთო მეთოდები /////////////// /////// //////////////////////////////////////////////////////////// ///// //////// // კლიენტზე //******** ბიზნეს ლოგიკა კლიენტზე ******* //******** გუნდი * ****** //******** კლიენტის ღონისძიებები ******* ///////////////////////// ///// ////////////////////////////////////////////////////////////// // / / პროგრამის მთავარი ოპერატორები

დაკავშირებული კითხვები
დასასრულს, ჩვენ გამოვყოფთ რამდენიმე სფეროს, რომლებზეც გამოსადეგია ფიქრი კლიენტ-სერვერის ურთიერთქმედების პროგრამირებისას.
  • დისტანციური წვდომის ინტერფეისის განხორციელების ვარიანტები. ასინქრონულობა, დეტალების დონე...
  • ქეშირება. 1C-მ მიიღო წარუმატებელი არქიტექტურული გადაწყვეტილება, შემოიღო ქეშირება მხოლოდ საერთო მოდულების გამოძახების მეთოდების დონეზე და არ უზრუნველყო საკონტროლო შესაძლებლობები (შესაბამისობის დრო, გადატვირთვა მოთხოვნით).
  • იმპლიციტური სერვერის ზარები. ნუ დაივიწყებთ ტექნოლოგიურ მახასიათებლებზე; კლიენტზე მრავალი „უვნებელი“ ოპერაცია იწვევს პლატფორმის სერვერთან დაკავშირებას.


 

შეიძლება სასარგებლო იყოს წაკითხვა: