Kontrollü formlar uv 1s açıklaması. StavAnalit

Hepimiz 1C şirketinin 1C platformunun birçok farklı sürümüne sahip olduğunu biliyoruz; şimdi bu makaleyi yazarken en son sürümlerden biriyle ilgileneceğiz, bunlar 1C 8.2 ve 1C 8.3 sürümleridir. Bu sürümlerin her ikisinde de çalışmak zorunda kaldıysanız, büyük olasılıkla bu sürümlerin arayüzlerinde farklar fark edildi, kullanıcılar için bunlar yalnızca görünüm açısından farklılık gösterir. Esasen bir seçim düzenli veya yönetilen uygulama sisteme çalıştırmak için hangi formların görüntüleneceğini söyler, düzenli veya kontrollü ve ayrıca varsayılan olarak kalın veya ince olarak hangi uygulama istemcisinin kullanılacağı. İstemciler hakkında daha ayrıntılı bilgi için "1C'de kalın ve ince istemciler nelerdir ve bunların farklılıkları" makalesini okuyun.

Normal 1C uygulaması (normal formlar, normal arayüz, sürüm 1C 8.2)

1C 8.2'de yalnızca çalışmak mümkündür normal formlarla, normal uygulama modunda. Aşağıdaki resim, veritabanını “normal 1C uygulaması” işletim modunda (normal formlar) göstermektedir.

Yönetilen 1C uygulaması (yönetilen formlar, yönetilen arayüz, sürüm 1C 8.3)

1C 8.3 platformunda hem normal formlarla (uyumluluk modunda) hem de yönetilen formlarla çalışabiliriz. Dahası yönetilen formların iki tür ekranı vardır; bu standart ve taksidir. Aşağıda standart yönetimli formlara sahip 1C 8.3 konfigürasyonunun bir örneği gösterilmektedir ve bundan sonra "Taksi" arayüzü gösterilmektedir.

Normal ve yönetilen 1C uygulaması arasındaki fark nedir?

Zaten öğrendiğimiz gibi normal bir uygulama ve yönetilen bir uygulama, bu tür bir 1C programını başlatma türleridir. Ayrıca, 1C başlatma türünün değerine bağlı olarak ( düzenli veya yönetilen uygulama), varsayılan olarak belirli bir arayüz yüklenecektir ( normal veya yönetilen formlar), dolayısıyla bu kavramın pek çok eşanlamlısı vardır. Arayüzlerdeki farklılıkların oldukça belirgin olduğunu belirtmek isteriz; yönetilen arayüz tamamen yeniden tasarlandı. Prensip olarak, bunlar 1C programının sıradan kullanıcılarının gördüğü tüm farklardır. Programcılara gelince, yönetilen arayüz değiştirilmiş kodun yazılmasını gerektirir, çünkü geliştirme zaten 1C 8.2'de değil 1C 8.3'te gerçekleştirilmiştir, dolayısıyla ortaya çıkan tüm sonuçlar. Kodun ayrıca istemci ve sunucuya bölünmesi gerekir; bu, yapılandırıcıdaki ilgili yönergeler kullanılarak gösterilir.

1C Enterprise 8.2 platformunun gelişiyle birlikte kullanıcı arayüzü geliştirme mekanizması önemli ölçüde değişti. Yönetilebilir formlar ve uygulamalar oluşturmak mümkün hale geldi (Şekil 1).

Resim 1

Ek olarak, işlevselliği istemci uygulaması ile sunucu arasında bölmek için yeni bir sistem önerilmektedir.
Yönetilen uygulama aşağıdaki istemci türlerini destekler:

  • Kalın istemci (normal ve yönetilen başlatma modu),
  • zayıf müşteri,
  • Web istemcisi.

Yönetilen formlar oluşturma mekanizması geleneksel olanlardan önemli ölçüde farklıdır. Öncelikle yönetilen formlar, sistem tarafından özel ayarlara dayalı olarak otomatik olarak oluşturuldukları gerçeğiyle ayırt edilir; programcının artık her formu ayrıntılı olarak çizmesine gerek yoktur. Formun tüm işlevleri ayrıntılar ve komutlar şeklinde açıklanmaktadır. Ayrıntılar formun birlikte çalıştığı verilerdir ve komutlar gerçekleştirilecek eylemlerdir. Her yöntem veya form değişkeni için yürütme konumunu (istemci veya sunucu) belirleyen bir derleme yönergesi belirtilmelidir. Derleme direktifleri aşağıdaki gibi olabilir:

  • &İstemcide,
  • &Sunucuda,
  • &OnServerWithoutContext,
  • &OnClientOnServerWithoutContext.

Yönetilen form, birlikte çalıştığı veri türleri açısından da normal formdan farklıdır. Normal form, 1C: Enterprise'ın sağladığı türlerin çoğuyla çalışıyorsa (DirectoryObject, DocumentObject vb. türleri dahil), yönetilen formda aşağıdaki tür kategorileri ayırt edilebilir:

  • formda doğrudan kullanılan türler, ince istemci ve Web istemcisinin yanında bulunan türlerdir (örneğin, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • özel veri türlerine dönüştürülecek türler (yönetilen form veri türleri). Bu türler form ayrıntıları listesinde parantez içinde görüntülenir; örneğin (DirectoryObject.Products);
  • dinamik liste.

Kontrollü formların işleyişi aşağıdaki ayırt edici özelliklere sahiptir (Şekil 2):

  • Form hem istemcide hem de sunucuda bulunur.

İstemci-sunucu etkileşimini (veri aktarımı ve elemanların tasarım özellikleri) gerçekleştirir.

  • Form uygulama nesneleriyle çalışmıyor


şekil 2

Formda özel evrensel nesneler kullanılır
Veri Formları(Figür 3).


Figür 3

Uygulama nesneleri yalnızca sunucuda ve yalnızca belirli işlemlerin yürütülmesi sırasında çalışır.
Formu açarken:

  • Nesne veritabanından okunur,
  • Nesne form verilerine dönüştürülür,
  • Nesne kaldırılır (bellekten),
  • Form verileri istemciye gönderilir.

Kayıt yaparken:

  • Form verileri istemciden alınır,
  • Form verileri bir nesneye dönüştürülür,
  • Nesne veritabanına yazılır,
  • Nesne kaldırılır (bellekten).

Diyelim ki 8.1 versiyonu için yazılmış harici bir işlem var. Eski, yönetilmeyen haliyle çalışması için 8.2'de çalıştırmak mümkün mü? İşleme, verileri aktarmak için yalnızca bir kez gereklidir ve bunun için yalnızca bir kez yönetilen bir form oluşturmak istemezsiniz...

Yönetilen modda harici işleme (ayrı bir dosyadan açılan) için normal formların kullanımı desteklenmez. Bu nedenle, yönetilen modda çalışan bir konfigürasyonda, işlemeye yönetilmeyen bir formla başlamak gerekiyorsa ve bu işleme için yeni, yönetilen bir form oluşturmak istemiyorsanız, bu tür işlemenin öncelikle konfigürasyona dahil edilmesi gerekir.

Normal (yönetilmeyen) formlar yalnızca kalın istemcide çalışabilir. İnce istemciler ve web istemcileri yalnızca yönetilen formları destekler.

Bu nedenle, yönetilen uygulama arayüzünde normal bir işlem formu açmanız gerekiyorsa, bu yalnızca yönetilen uygulama modunda çalışan kalın bir istemcide mümkündür.

En kolay yol, kalın istemciyi, parametrelerde belirterek yapılandırıcıdan yönetilen uygulama modunda başlatmaktır: Hizmet - Seçenekler - 1C:Enterprise'ı başlatın - Temel - Kalın istemci (yönetilen uygulama).

Ancak, istemcileri yönetilen modda başlatmanın yalnızca yapılandırmanın sürüm 8.1 uyumluluğunun devre dışı bırakılması durumunda mümkün olduğunu hatırlamanız gerekir (özellik Uyumluluk modu).

Ancak bu, platformun eski, yönetilmeyen işleme biçimini açması için yeterli değil.

Düzenli formları kontrollü modda kullanma yeteneği, özel bir konfigürasyon özelliği ile düzenlenir - Yönetilen Bir Uygulamada Normal Formları Kullanma. Bu özelliğin ayarlanması gerekiyor.

Konfigürasyon özellikleri paletinde bu özellik her zaman görüntülenmez, ancak yalnızca konfigüratör parametrelerinde konfigürasyon düzenleme modu Yönetilen uygulama ve normal uygulama seçildiğinde görüntülenir ( Servis - Seçenekler - Genel).

Ve son olarak yönetilen modda normal formunu görmek istediğiniz nesnenin tek bir ana nesne formuna sahip olması ve bu formun normal, yönetilmeyen olması gerekir.

Diğer durumlarda (nesnenin herhangi bir ana formu yoksa veya nesnenin yönetilen bir ana formu varsa), platform varsayılan olarak yönetilen formu oluşturur veya açar (varsa).

Asıl sorun, 10-15 yıldan fazla bir süredir sıradan formlar için çok sayıda kodun derlenmiş olmasıdır. Hiç kimse tüm bunları istemci-sunucuya yeniden yazmak istemez; birçok kişi arayüzle çalışmak üzere eğitilmiştir. Gelecek yıldan itibaren BP 3.0'a zorunlu geçiş, geliştiricilerin ve muhasebecilerin kafasında panik yaratıyor. Geri bildirim çok tatsız olacaktır. Ayrıca mesleğe girişte çıta yükseliyor, programlama zorlaşıyor, standart olanlar ise daha da zorlaşıyor. Yeni algoritmanın standart belgelerdeki maliyeti nedir? Belgelerin üzerinde 2-3 düğme olduğunda UV harika görünür; UV, mobil cihazlarda çalışmak için harikadır ancak şirketlerin yalnızca %0,01'i bunu kullanıyor. 1C yeni bir şey bulamazsa geçiş yapmak zorunda kalacaksınız, ancak bu herkes için uzun ve acı verici olacak. Ve şirketlerin kendileri parayı ödemek zorunda kalacak.

Ben de şimdiye kadar kontrollü formlardan sadece olumsuz şeyler yaşadım, işte yeniliğin bazı dezavantajları:

  • Hiç bir şey? Bununla birkaç kez karşılaştım, örneğin, ZUP conf'a harici bir baskı formu yazıp eklemek, orada bir destan işlemek, internetteki talimatlarla ve kod sayfalarıyla dolu.
    kalın bir istemcide parametrelere sahip bir prosedür vardır; geliştirme birkaç dakika meselesidir.
    ve frenler çıplak gözle görülebilecek kadar ince
  • Yönetilebilir formlar hazırlayabilme konusuna gelince; bu sanat için sanattır, ama özellikle dosya versiyonu açısından pratik nokta nedir?
  • 3 yıl boyunca UV'de heykel yaptım ama şimdi tekrar basit formlara döndüm ve inanın psikolojik olarak bu geçişi yapmak oldukça zordu ama bu benim bilinçli seçimim çünkü 1c'nin UV'de sunduğu şey tamamen UG.... belki birkaç yıl içinde 1c bir atılım yapabilir ama şimdi o sadece bu atılımı nerede yapabileceğini arıyor...
  • Yapılandırıcıdaki UV'lerin açılması çok daha uzun sürer.
    Bundan sonra 8.1'de form açmak kamyondan uçağa geçmek gibi!
  • Herkes için daha fazla sorun var, kullanıcılar yeni arayüz karşısında şok oluyor (herkes bunu kabul etmiyor, ancak küçük şeyler konusunda çok daha aptallar), programcıların yarısı profesyonelliğe uygun değil, ortalama bir uzmanın bunu yapması zorlaştı. iş bulma ve kaliteli bir ürünün nasıl üretileceği. Ve UV'nin en harika pazarlama teması, basit bir güncellemeyle geçişin gerçekleştiği her yere uçmaları, ancak herkes en başından itibaren en son sürümleri yakalamanız gerektiğini unutuyor! Ama prensip olarak bu fikri beğendim!
  • Bilmiyorum, deneyimlerim tam tersini gösteriyor. Birkaç yıldır katı formlardaki bomların otomatik olarak vurduğu yerlerde, yeni UV standardında her ay "neden, bu düğmeyi güncelledikten sonra 1C şimdi nerede ve neden şimdi çalışmıyor" diye başlıyor ki, görüyorsunuz , hız eklemez.
  • - daha fazla kod var
    - kod daha karmaşık hale geldi
    — standart olanların değiştirilmesi çok daha zordur
    - UT11 verdiğim kullanıcılar 10.x'e göre hiçbir avantaj bulamadılar
    — ancak bazı yavaşlamalar ve arama gibi bazı işlevlerin eksikliğini buldular (bazı nedenlerden dolayı seçim değil ileri-geri arama istediler)
    Benim fikrim, web istemcisi ve tabletler uğruna yapılan fedakarlıkların çok büyük olduğu yönünde. Üstelik kişisel olarak, uzaktan erişimi başarıyla kullanması gereken bir web istemcisiyle henüz gerçek bir çalışma görmedim.
  • İstemci-sunucu karmaşası performans ve ölçeklenebilirlikte artış sağlamalı, aynı zamanda maliyetler kodlamada artışı da içermelidir.
    Ancak herkes bir artış yaşamadı, dolayısıyla hayal kırıklığı yaşandı. Ve aynı zamanda herkes kodlama maliyetlerine odaklanmıştı.
    Not: Aslında kontrollü olanları seviyorum, sakince onlardan yararlanıyorum. Ama tipik olanlar sapkınlaştı.
  • Evde (normal bilgisayar) bireysel girişimcilere göre içki içmemi yürütüyorum.
    8.3, BP3, kareli. Ana izlenim şu ki çalışmıyorum ama her zaman bekliyorum. hemoroidal yanıt. Hesabın SALT'ı tek kelimeyle şaşırtıcı bir şekilde oluşturulmuş; bir mega holdingin yıllık hesap kartı gibi görünüyor.
  • UT11 vahşi bir fren, korku ve genel olarak bir kabustur.
    UT10, UT11'e kıyasla uçuyor.
    UV'ye gelince; böcekler yıllardır istila edilmiş, her şey çarpık, sütunlar hiçbir zaman tek bir ekrana sığmıyor, çoğu durumda esneme berbat.
    Ve hala birçok eksiyi sıralayabilirim ama muhtemelen artılar hakkında hiçbir şey söylemeyeceğim. Onlar basitçe mevcut değiller.
    Firmalar özellikle bu formları kullandılar, çünkü geliştirme maliyeti daha yüksekti, ne özel ne de normal formlar vardı.

Birkaç avantajı var, ama elbette varlar...

artıları:

UP'nin verdiği cevap uzun zamandır ortadaydı:

çapraz platform istemcisi

  • Kötü iletişim hatlarında çalışmak
  • bir tarayıcı üzerinden çalışma yeteneği (istemci kurmadan)

Ve Veri Aktarım Nesnesinden kod yapılanmasına, 1C 8.2 ortamında kontrollü form.

giriiş

"Yönetilen form" kavramının ve 1C platformunun ilgili kavramlarının kısa bir açıklamasıyla başlayalım. Platform uzmanları bu bölümü atlamak isteyebilir.

2008 yılında, 1C platformunun yeni bir sürümü kullanıma sunuldu: Enterprise 8.2 (bundan sonra Yönetilen Uygulama olarak anılacaktır), bu da arayüz ile tüm çalışma katmanını tamamen değiştirir. Buna komut arayüzü, formlar ve pencere sistemi dahildir. Aynı zamanda, konfigürasyonda kullanıcı arayüzünün geliştirilmesine yönelik modelin değiştirilmesinin yanı sıra, istemci uygulaması ile sunucu arasındaki işlevselliğin ayrılmasına yönelik yeni bir mimari de önerilmektedir.
Yönetilen uygulama aşağıdaki istemci türlerini destekler:

  • Kalın istemci (normal ve yönetilen başlatma modu)
  • Zayıf müşteri
  • Web istemcisi
Yönetilen uygulama, yeni teknolojiye dayanan formları kullanır. Onlar aranmaktadır Yönetilen Formlar. Geçişi kolaylaştırmak için önceki formlar (Normal formlar olarak da bilinir) de desteklenir, ancak işlevleri geliştirilmemiştir ve yalnızca kalın istemci başlatma modunda kullanılabilirler.
Bir geliştirici için yönetilen formların temel farklılıkları:
  • Yapının "piksel piksel" değil bildirimsel açıklaması. Form görüntülendiğinde elemanların spesifik yerleşimi sistem tarafından otomatik olarak gerçekleştirilir.
  • Formun tüm işlevleri şu şekilde tanımlanır: detaylar Ve takımlar. Ayrıntılar formun birlikte çalıştığı verilerdir ve komutlar gerçekleştirilecek eylemlerdir.
  • Form hem sunucuda hem de istemcide çalışır.
  • İstemci bağlamında neredeyse tüm uygulama türleri mevcut değildir ve dolayısıyla bilgi tabanındaki verileri değiştirmek imkansızdır.
  • Her yöntem veya form değişkeni için belirtilmelidir derleme direktifi, yürütme konumunu (istemci veya sunucu) ve form içeriğine erişimi tanımlama.
Form yöntemlerini derlemek için yönergeleri listeleyelim:
  • &İstemcide
  • &Sunucuda
  • &SunucudaBağlam Olmadan
  • &OnClientOnServerBağlam Olmadan
Yukarıdakileri örnekleyelim. Ekran görüntüsü, yönetilen bir formun ve onun modülünün geliştirme modundaki bir örneğini gösterir. Bildirim niteliğindeki açıklamayı, destekleri, derleme yönergelerini vb. bulun.

Bundan sonraki tüm tartışmalar, şeklin sağ tarafı, modül kodunun nasıl yapılandırılacağı ve hangi ilkelerin etkili istemci-sunucu etkileşimini uygulamanıza izin vereceği hakkında olacaktır.

Sorunu tanımlayalım

1C platformunun yeni sürümünün aktif olarak kullanılmasının üzerinden birkaç yıl geçti ve hem 1C hem de birçok ortağı tarafından birçok çözüm (konfigürasyon) yayınlandı.
Bu süre zarfında geliştiriciler, formlar oluştururken istemci-sunucu etkileşimi ilkelerine ilişkin ortak bir anlayış geliştirdiler mi ve yeni mimari gerçekliklerde yazılım modüllerinin uygulanmasına yönelik yaklaşım değişti mi?

Aynı standart konfigürasyonun çeşitli formlarındaki kod yapısına (form modülü) bakalım ve kalıpları bulmaya çalışalım.
Yapı derken, geliştirici tarafından grup yöntemlerine ve bu yöntemlere yönelik derleme yönergelerine tahsis edilen kod bölümlerini (çoğunlukla bunlar yorum bloklarıdır) kastediyoruz.
Örnek 1:
Olay işleyicileri bölümü Yöntem - istemcide Yöntem - sunucuda Yöntem - istemcide Hizmet prosedürleri ve işlevleri bölümü Yardımcı giriş kontrol işlevleri
Örnek 2:
Hizmet prosedürleri ve işlevleri Ödeme belgeleri Değerler Olay yöneticileri
Örnek 3:
Sunucudaki hizmet yordamları İstemcideki hizmet yordamları Bağlam olmadan sunucudaki hizmet yordamları Başlık olay işleyicileri Komut olay işleyicileri
Örnek 4:
Genel amaçlı prosedürler Form olay yöneticileri "İletişim bilgileri" alt sisteminin prosedürleri
Temelde kod yapısı eksik veya en hafif tabirle Form 8.1'dekine benziyor:

  • Bilgilendirici olmayan kelimeler “Genel, Hizmet, Yardımcı”.
  • Timid, istemci ve sunucu yöntemlerini ayırmaya çalışır.
  • Yöntemler genellikle "Ürünler tablo bölümüyle çalışma, İletişim bilgileri" arayüz öğelerine göre gruplandırılır.
  • Yöntemlerin ve kod gruplarının keyfi düzenlenmesi. Örneğin, Olay İşleyicileri bir formda en üstte, diğerinde en altta olabilir, üçüncü formda hiç vurgulanmamış olabilir, vb.
  • Ve bunların hepsinin tek bir konfigürasyonda olduğunu unutmayalım.
  • Evet “Genel, Servis, Yardımcı” kelimelerinin hep aynı yerde olduğu konfigürasyonlar var ama...
Neden kod yapısına ihtiyacınız var?
  • Bakımın basitleştirilmesi.
  • Öğrenmeyi basitleştirin.
  • Genel/önemli/başarılı ilkelerin kaydedilmesi.
  • ...sizin seçeneğiniz
1C'nin mevcut geliştirme standardı neden yardımcı olmuyor?
Yönetilen bir form yazarken önerilen ITS disklerinde ve çeşitli “Geliştirici Kılavuzlarında...” yayınlanan ilkelere bakalım.
  • Sunucu çağrılarının sayısını en aza indirin.
  • Sunucuda maksimum bilgi işlem.
  • Bağlamsal olmayan sunucu çağrıları bağlamsal olanlardan daha hızlıdır.
  • İstemci-sunucu iletişimini göz önünde bulunduran program.
  • ve benzeri.
Bunlar kesinlikle doğru sloganlar ama nasıl uygulanmalı? Çağrı sayısı nasıl en aza indirilir, istemci-sunucu modunda programlama ne anlama gelir?

Tasarım kalıpları veya nesil bilgeliği

İstemci-sunucu etkileşimi onlarca yıldır çeşitli yazılım teknolojilerinde kullanılmaktadır. Önceki bölümde özetlenen soruların cevabı uzun zamandır bilinmektedir ve iki temel prensipte özetlenmiştir.
  • Uzak Cephe(bundan böyle Uzaktan Erişim Arayüzü olarak anılacaktır)
  • Veri Aktarım Nesnesi(bundan böyle Veri Aktarım Nesnesi olarak anılacaktır)
Martin Fowler'ın bu ilkelere ilişkin açıklaması:
  • … Potansiyel olarak uzaktan erişime yönelik her nesnenin sahip olması gerekir. düşük tanecikli arayüz Bu, belirli bir prosedürü gerçekleştirmek için gereken çağrı sayısını en aza indirecektir. ... Fatura ve tüm kalemlerini ayrı ayrı talep etmek yerine, tek talepte tüm fatura kalemlerini okuyup güncellemeniz gerekiyor. Bu, nesnenin tüm yapısını etkiler...Unutmayın: uzaktan erişim arayüzü etki alanı mantığı içermiyor.
  • ...eğer şefkatli bir anne olsaydım çocuğuma kesinlikle şunu derdim: "Asla veri aktarım nesneleri yazmayın!" Çoğu durumda, veri aktarım nesneleri yalnızca şişirilmiş alan seti... Bu iğrenç canavarın değeri yalnızca olasılıkta yatıyor tek bir çağrıda ağ üzerinden birden fazla bilgi iletin- Dağıtılmış sistemler için büyük önem taşıyan bir teknik.
1C platformundaki şablon örnekleri
Yönetilen bir form geliştirirken geliştiricinin kullanabileceği uygulama programlama arayüzü bu ilkelerin birçok örneğini içerir.
Örneğin, tipik bir "kaba" arayüz olan OpenForm() yöntemi.
OpeningParameters = Yeni Yapı("Parametre1, Parametre2, Parametre3", Değer1, Değer2, Değer3); Form = OpenForm(FormAdı, OpeningParameters);
V8.1'de benimsenen stille karşılaştırın.
Form = GetForm(FormAdı); Form.Parametre1 = Değer1; Form.Parametre2 = Değer2; Form.Open();

Yönetilen bir form bağlamında birçok “Veri Aktarım Nesnesi” vardır. seçebilirsiniz sistemik Ve geliştirici tanımlı.
Sistem olanlar, istemci üzerinde bir uygulama nesnesini bir veya daha fazla form veri öğesi biçiminde modeller. Form ayrıntılarına başvurmadan bunları oluşturmak imkansızdır.

  • VeriFormlarıYapısı
  • VeriFormlarıKoleksiyonu
  • DataFormStructureWithCollection
  • Veri Şekilleri Ağacı
Sistem veri aktarım nesnelerinin uygulama türlerine (veya tam tersi) dönüştürülmesi aşağıdaki yöntemler kullanılarak gerçekleştirilir:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Mevcut bir çözümü uyarlarken genellikle açık dönüşüm kullanılır. Yöntemler, FormDataCollection yerine ValueTable gibi giriş parametrelerini bekleyebilir (özellikleri kullanabilir) veya yöntem bir uygulama nesnesi bağlamında tanımlanmış ve formdan doğrudan çağrı için kullanılamaz hale gelmiştir.
Örnek 1C v8.1:
// istemcide FillUserCache(DepartmentLink) formu bağlamında
Örnek 1C v8.2:
// sunucuda form bağlamında ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Yapısı geliştirici tarafından belirlenen veri aktarım nesneleri, hem istemcide hem de sunucuda bulunan türlerin küçük bir alt kümesidir. Çoğu zaman, aşağıdakiler "kabalaştırılmış" bir arayüzün parametreleri ve yöntemlerinin sonuçları olarak kullanılır:

  • İlkel türler (dize, sayı, boolean)
  • Yapı
  • Yazışma
  • Sıralamak
  • Uygulama nesnelerine bağlantılar (benzersiz tanımlayıcı ve metin gösterimi)
Örnek: yöntem, durumu değiştirmek için bir sipariş listesini kabul eder ve istemciye hataların bir açıklamasını döndürür.
&OnServerWithoutContext İşlev ServerChangeOrderStatus(Orders, NewStatus) Hatalar = Yeni Eşleşme(); // [sipariş][hata açıklaması] Siparişlerden Her Sipariş İçin Cycle StartTransaction(); DocOb = Order.GetObject();'i deneyin …. diğer eylemler, yalnızca siparişle mümkün değildir... İstisna CancelTransaction(); Errors.Insert(Order, ErrorDescription()); Deneme Sonu; EndCycle; Dönüş Hatası; EndFunction // ServerChangeOrderStatus()

Kodun yapılandırılması

Yönetilen form modülünün yansıtması gereken temel hedefler ve çözüme yaklaşımlar.
  • İstemci ve sunucu kodunun net bir şekilde ayrılması. Yürütme sırasında bunların, her biri önemli ölçüde farklı işlevselliğe sahip, etkileşim halindeki iki süreç olduğunu unutmayalım.
  • Uzaktan erişim arayüzünün açık bir şekilde tanımlanması; istemciden hangi sunucu yöntemlerinin çağrılabileceği ve hangilerinin çağrılamayacağı? Uzak arayüz yöntemlerinin adları "Sunucu" önekiyle başlar. Bu, kodu okurken kontrolün sunucuya aktarıldığını anında görmenize olanak tanır ve bağlamsal yardımın kullanımını basitleştirir. Resmi önerinin (ITS), ChangeOrderStatusOnServer() gibi soneklerle adlandırma yöntemleri önerdiğini unutmayın. Ancak tüm sunucu yöntemlerinin istemciden çağrılamadığını ve bu nedenle derleme konumundan ziyade mantıksal erişilebilirliğin daha önemli olduğunu tekrarlıyoruz. Bu nedenle, “Server” önekiyle yalnızca istemcinin kullanabileceği yöntemleri işaretliyoruz; örnek yöntemi ServerChangeOrderStatus() olarak adlandıralım.
  • Okunabilirlik. Zevk meselesi, sunucuda form oluşturma prosedürleri ve uzaktan erişim yöntemleri ile modül başladığında siparişi kabul ediyoruz.
  • Sürdürülebilirlik. Yeni kod eklemek için açık bir konum olmalıdır. Önemli bir nokta, yapılandırıcı tarafından otomatik olarak oluşturulan yöntem şablonlarının modülün sonuna eklenmesidir. Form öğelerine ilişkin olay işleyicileri çoğunlukla otomatik olarak oluşturulduğundan, her işleyiciyi modülde başka bir yere sürüklememek için karşılık gelen blok en sona yerleştirilir.
Aşağıda listelenen hedefleri uygulayan modülün temel yapısı verilmiştir.
  • Grafik seçeneği – ana yürütme akışını açıkça gösterir.
  • Metin seçeneği, yeni bir form modülüne hızlı bir şekilde bir yapı eklemek için kullanılan şablon tasarımının bir örneğidir.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Tarih=""/> // <Описание> // // //////////////////////////////////////////////// // //////////////////////////// // MODÜL DEĞİŞKENLERİ ///////////////// // ////////////////////////////////////////////// //// ////////// // SUNUCUDA //******** SUNUCUDAKİ OLAYLAR ******* &Sunucuda Sunucuda Oluşturulduğunda Prosedür (Arıza, Standart İşleme) / /İşleyicinin içeriğini ekleyin Prosedür Sonu //******* UZAKTAN ERİŞİM ARAYÜZÜ ******* //******* SUNUCUDA İŞ MANTIĞI ******* ///////// ////////////////////////////////////////// /////// ///////////////////// // İSTEMCİ VE SUNUCUSUN ORTAK YÖNTEMLERİ /////////////// /////// /////////////////////////////////////////// ///// //////// // MÜŞTERİ ÜZERİNDE //******* İŞ MÜŞTERİ ÜZERİNDE İŞ MANTIĞI ******* //******** EKİP * ****** //******** MÜŞTERİ OLAYLARI ******* ////////////////////////// ///// ///////////////////////////////////////////// // / / ANA PROGRAM OPERATÖRLERİ

İlgili sorular
Sonuç olarak, istemci-sunucu etkileşimini programlarken dikkate alınması yararlı olan birkaç alanın ana hatlarını çizeceğiz.
  • Uzaktan erişim arayüzü uygulama seçenekleri. Eşzamansızlık, ayrıntı düzeyi...
  • Önbelleğe almak. 1C, yalnızca ortak modüllerin çağrı yöntemleri düzeyinde önbelleğe almayı başlatan ve kontrol yetenekleri (alaka süresi, talep üzerine sıfırlama) sağlamayan başarısız bir mimari karar verdi.
  • Örtülü sunucu çağrıları. Teknolojik özellikleri unutmayın; istemcideki birçok “zararsız” işlem, platformun sunucuyla iletişim kurmasına neden olur.


 

Okumak faydalı olabilir: