Nadzorovane oblike uv 1s opis. StavAnalit

Vsi vemo, da je imelo podjetje 1C veliko različnih različic platforme 1C; zdaj nas bo zanimala ena najnovejših različic v času pisanja tega članka, to sta različici 1C 8.2 in 1C 8.3. Če ste morali delati v obeh različicah, potem najverjetneje opazili razlike v vmesnikih teh različic, za uporabnike se razlikujejo le po videzu. V bistvu izbira redna ali upravljana aplikacija pove sistemu, katere obrazce naj prikaže za zagon, redno ali kontrolirano, kot tudi, kateri odjemalec aplikacije bo privzeto uporabljen, debel ali tanek. Za podrobnejše informacije o strankah preberite članek »Kaj so debeli in tanki odjemalci v 1C, pa tudi njihove razlike«.

Navadna aplikacija 1C (običajni obrazci, običajni vmesnik, različica 1C 8.2)

V 1C 8.2 je mogoče delati samo z običajnimi obrazci, v običajnem načinu prijave. Spodnja slika prikazuje bazo podatkov v načinu delovanja »navadna aplikacija 1C« (navadne forme).

Upravljana aplikacija 1C (upravljani obrazci, upravljani vmesnik, različica 1C 8.3)

Na platformi 1C 8.3 lahko delamo tako z običajnimi obrazci (v združljivem načinu) kot z upravljanimi. Poleg tega upravljani obrazci imajo dve vrsti prikaza, to je standardni in taksi. Spodaj je prikazan primer konfiguracije 1C 8.3 s standardnimi upravljanimi obrazci, za njim pa je prikazan vmesnik "Taxi".

Kakšna je razlika med običajno in upravljano aplikacijo 1C?

Kot smo že ugotovili običajna aplikacija in upravljana aplikacija sta ti vrsti zagona programa 1C. Poleg tega je odvisno od vrednosti vrste zagona 1C ( redna ali upravljana aplikacija), bo privzeto naložen določen vmesnik ( redne ali upravljane oblike), zato obstaja toliko sinonimov za ta koncept. Opozarjamo, da so razlike v vmesnikih precejšnje; upravljani vmesnik je popolnoma prenovljen. Načeloma so to vse razlike, ki jih vidijo običajni uporabniki programa 1C. Kar zadeva programerje, upravljani vmesnik zahteva pisanje spremenjene kode, ker je razvoj že izveden v 1C 8.3 in ne v 1C 8.2, zato vse posledice, ki izhajajo iz tega. Koda mora biti razdeljena tudi na odjemalca in strežnika; to je označeno z ustreznimi direktivami v konfiguratorju.

S prihodom platforme 1C Enterprise 8.2 se je mehanizem razvoja uporabniškega vmesnika bistveno spremenil. Postalo je mogoče ustvariti upravljane obrazce in aplikacije (slika 1).

Slika 1

Poleg tega je predlagan nov sistem za delitev funkcionalnosti med odjemalsko aplikacijo in strežnikom.
Upravljana aplikacija podpira naslednje vrste odjemalcev:

  • Debel odjemalec (običajen in upravljan način zagona),
  • tanek odjemalec,
  • Spletni odjemalec.

Mehanizem za ustvarjanje upravljanih obrazcev se bistveno razlikuje od običajnih. Upravljane obrazce odlikuje predvsem to, da jih sistem ustvari samodejno na podlagi posebnih nastavitev, programerju sedaj ni treba posebej risati vsakega obrazca. Vse funkcionalnosti obrazca so opisane v obliki podrobnosti in ukazov. Podrobnosti so podatki, s katerimi deluje obrazec, ukazi pa so dejanja, ki jih je treba izvesti. Za vsako metodo ali spremenljivko obrazca je treba podati direktivo prevajanja, ki določa lokacijo izvajanja (odjemalec ali strežnik). Navodila za prevajanje so lahko naslednja:

  • &Na odjemalcu,
  • &Na strežniku,
  • &Na strežniku brez konteksta,
  • &OnClientOnServerWithoutContext.

Upravljani obrazec se od navadnega obrazca razlikuje tudi po vrstah podatkov, s katerimi deluje. Če običajni obrazec deluje z večino vrst, ki jih ponuja 1C: Enterprise (vključno s tipi DirectoryObject, DocumentObject itd.), potem lahko v upravljani obliki ločimo naslednje kategorije vrst:

  • tipi, ki se neposredno uporabljajo v obrazcu, so tisti tipi, ki obstajajo na strani tankega in spletnega odjemalca (na primer Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • vrste, ki bodo pretvorjene v posebne podatkovne vrste – podatkovne vrste upravljanih obrazcev. Takšni tipi so prikazani na seznamu podrobnosti obrazca v oklepajih, na primer (DirectoryObject.Products);
  • dinamični seznam.

Delovanje nadzorovanih oblik ima naslednje posebnosti (slika 2):

  • Obrazec obstaja tako na odjemalcu kot na strežniku.

Izvaja interakcijo odjemalec-strežnik (prenos podatkov in oblikovnih lastnosti elementov).

  • Obrazec ne deluje z objekti aplikacije


Slika 2

Obrazec uporablja posebne univerzalne predmete
DataForms(Slika 3).


Slika 3

Aplikacijski objekti delujejo samo na strežniku in samo med izvajanjem določenih operacij.
Ko odprete obrazec:

  • Objekt se prebere iz baze podatkov,
  • Predmet se pretvori v podatke obrazca,
  • Predmet je odstranjen (iz spomina),
  • Podatki obrazca se pošljejo naročniku.

Pri snemanju:

  • Podatke obrazca pridobimo od naročnika,
  • Podatki obrazca se pretvorijo v objekt,
  • Objekt je zapisan v bazo podatkov,
  • Predmet je odstranjen (iz spomina).

Recimo, da obstaja zunanja obdelava, napisana za različico 8.1. Ali ga je mogoče zagnati v 8.2, tako da deluje s svojo starejšo, neupravljano obliko? Obdelava je potrebna samo enkrat, za prenos podatkov, in ne želite ustvariti upravljanega obrazca za to samo enkrat ...

Za zunanjo obdelavo (odprto iz ločene datoteke) v upravljanem načinu uporaba navadnih obrazcev ni podprta. Če je torej v konfiguraciji, ki deluje v upravljanem načinu, potrebno začeti obdelavo z neupravljanim obrazcem in za to obdelavo ne želite ustvariti novega, upravljanega obrazca, je treba takšno obdelavo najprej vključiti v konfiguracijo.

Običajni (neupravljani) obrazci lahko delujejo samo v debelem odjemalcu. Lahki in spletni odjemalci podpirajo samo upravljane obrazce.

Če morate torej v vmesniku upravljane aplikacije odpreti običajen obrazec za obdelavo, je to mogoče samo v debelem odjemalcu, ki se izvaja v načinu upravljane aplikacije.

Najlažji način je, da debelega odjemalca zaženete v načinu upravljane aplikacije iz konfiguratorja in to določite v parametrih: Storitev – Možnosti – Zagon 1C:Enterprise – Osnovno – Debel odjemalec (upravljana aplikacija).

Vendar si morate zapomniti, da je zagon odjemalcev v upravljanem načinu mogoč le, če je v konfiguraciji onemogočena združljivost z različico 8.1 (lastnost Način združljivosti).

Vendar to ni dovolj, da bi platforma odprla staro, neupravljano obliko obdelave.

Možnost uporabe običajnih obrazcev v nadzorovanem načinu ureja posebna konfiguracijska lastnost - Uporabite običajne obrazce v upravljani aplikaciji. To lastnost je treba nastaviti.

V paleti konfiguracijskih lastnosti ta lastnost ni vedno prikazana, ampak le, če je v parametrih konfiguratorja izbran način urejanja konfiguracije Upravljana aplikacija in običajna aplikacija ( Storitev – Možnosti – Splošno).

In končno, predmet, katerega običajno obliko želite videti v upravljanem načinu, mora imeti eno glavno obliko predmeta, ta oblika pa mora biti normalna, neupravljana.

V drugih primerih (če objekt nima nobenega glavnega obrazca ali ima objekt upravljani glavni obrazec), bo ogrodje privzeto ustvarilo ali odprlo (če ga ima) upravljani obrazec.

Glavna težava je, da je bilo v 10-15 letih že sestavljeno veliko kode za navadne obrazce. Nihče ne želi vsega tega prepisati na odjemalec-strežnik + veliko ljudi je usposobljenih za delo z vmesnikom. Obvezen prehod na BP 3.0, ki se začne naslednje leto, povzroča paniko v glavah razvijalcev in računovodij. Povratne informacije bodo zelo neprijetne. Poleg tega se letvica za vstop v poklic dviguje, programiranje je težje, standardni pa so postali še težji. Kakšna je cena novega algoritma v standardnih dokumentih? UV izgleda odlično, ko imate na dokumentih 2-3 gumbe, UV je odličen za delo na mobilnih napravah, vendar ga uporablja le 0,01% podjetij. Morali boste zamenjati, če 1C ne bo pripravil česa novega, vendar bo to dolgo in boleče za vse. In podjetja bodo morala plačati denar.

Tudi jaz sem do sedaj izkusil samo negativne stvari od kontroliranih oblik, še nekaj slabosti novosti:

  • nič? No, nekajkrat sem naletel na primer pisanje in pripenjanje eksterne tiskovne forme na ZUP conf, tam je obdelava cela epopeja, navodil je ogromno na internetu in strani kode bi moralo.
    na debelem odjemalcu obstaja en postopek s parametri, tj. razvoj je stvar nekaj minut.
    in zavore so tanke, vidne s prostim očesom
  • Kar zadeva možnost priprave obvladljivih obrazcev - to je umetnost zaradi umetnosti, toda kaj je praktična točka, zlasti pri datotečni različici?
  • 3 leta sem kiparil v UV, zdaj pa sem prešel nazaj na preproste forme in verjemite mi, da je bil ta prehod psihološko precej težko narediti, vendar je to moja zavestna izbira, ker to, kar ponuja 1c v UV, je popolnoma UG…. mogoče bo čez par let 1c naredila preboj, zdaj pa samo išče prostor, kjer bi naredila ta preboj...
  • Odpiranje UV-jev v konfiguratorju traja veliko dlje.
    Po tem je odpiranje obrazcev v 8.1 kot prestop iz tovornjaka na letalo!
  • Težav je za vse več, uporabniki so šokirani nad novim vmesnikom (vsi tega ne priznajo, ampak so veliko bolj neumni glede manjših stvari), polovica programerjev je postala neprimerna za strokovnost, povprečnemu strokovnjaku je postalo težje najti službo in kako izdelati kvaliteten izdelek. In najbolj kul marketinška tema UV je, da se dvignejo povsod, da se prehod zgodi s preprosto posodobitvijo, vendar vsi pozabljajo, da morate od začetka dohiteti najnovejše izdaje! Ampak načeloma mi je ideja všeč!
  • Ne vem, moje izkušnje kažejo nasprotno. Tam, kjer so boomi v strogih obrazcih že nekaj let samodejno udarjali, se v novih standardih UV vsak mesec začne "zakaj, kje je zdaj 1C po posodobitvi tega gumba in zakaj zdaj ne deluje," kar vidite , ne dodaja hitrosti.
  • - kode je več
    - koda je postala bolj zapletena
    — spreminjanje standardnih je veliko težje
    - uporabniki, ki sem jim dal UT11, niso našli prednosti v primerjavi z 10.x
    — vendar so ugotovili nekaj upočasnitev in pomanjkanje nekaterih funkcij, kot je iskanje (iz neznanega razloga so želeli iskanje naprej-nazaj in ne izbire)
    Moje mnenje je, da so žrtve prevelike za dobrobit spletnega odjemalca in tablic. Še več, osebno še nisem videl pravega dela s spletnim odjemalcem, ki bi moral uspešno uporabljati oddaljeni dostop
  • Bedlam odjemalec-strežnik naj bi zagotovil povečanje zmogljivosti in razširljivosti, hkrati pa stroški vključujejo povečanje kodiranja.
    Niso pa vsi občutili povečanja, zato razočaranje. In hkrati so bili vsi osredotočeni na stroške kodiranja.
    P.S. Pravzaprav imam rada tiste kontrolirane, mirno jih črpam. Tisti tipični pa so postali sprevrženi.
  • Doma (navaden računalnik) pitje vodim po posameznih podjetnikih.
    8.3, BP3, karirasto. Glavni vtis je, da ne delam, ampak ves čas čakam. odziv na hemoroide. SALT za račun je oblikovan tako preprosto kot hudič - zdi se kot računska kartica za leto v mega-holdingu.
  • UT11 je divja zavora, groza in nasploh nočna mora.
    UT10 leti v primerjavi z UT11.
    Kar zadeva UV - hrošči so okuženi že leta, vse je ukrivljeno, stolpci se nikoli ne prilegajo enemu zaslonu, raztezanje je v mnogih primerih grozno.
    In še veliko minusov lahko naštejem, o plusih pa verjetno ne bom nič rekel. Preprosto ne obstajajo.
    Konkretno so podjetja končala s temi oblikami, ker razvoj stane več, posebnih ni bilo in ni običajnih.

Prednosti je malo, a seveda obstajajo...

Pros:

Odgovor je že dolgo tam, kar je dal UP:

medplatformni odjemalec

  • delo na slabih komunikacijskih linijah
  • možnost dela prek brskalnika (brez namestitve odjemalca)

In objekt prenosa podatkov v strukturiranje kode, nadzorovana oblika v okolju 1C 8.2.

Uvod

Začnimo s kratkim opisom koncepta "upravljane oblike" in povezanih konceptov platforme 1C. Poznavalci platform bodo morda želeli preskočiti ta razdelek.

Leta 2008 je bila na voljo nova različica platforme 1C: Enterprise 8.2 (v nadaljevanju Upravljana aplikacija), ki popolnoma spremeni celotno plast dela z vmesnikom. To vključuje ukazni vmesnik, obrazce in okenski sistem. Hkrati se ne spremeni samo model razvoja uporabniškega vmesnika v konfiguraciji, temveč je predlagana tudi nova arhitektura za ločevanje funkcionalnosti med odjemalsko aplikacijo in strežnikom.
Upravljana aplikacija podpira naslednje vrste odjemalcev:

  • Debel odjemalec (običajen in upravljan način zagona)
  • Tanek odjemalec
  • Spletni odjemalec
Upravljana aplikacija uporablja obrazce, zgrajene na novi tehnologiji. Imenujejo se Upravljani obrazci. Za lažji prehod so podprti tudi predhodni obrazci (t.i. navadni obrazci), vendar njihova funkcionalnost ni razvita in so na voljo samo v načinu zagona debelega odjemalca.
Glavne razlike med upravljanimi obrazci za razvijalca:
  • Deklarativni, ne "piksel za pikselom" opis strukture. Določeno postavitev elementov sistem izvede samodejno, ko je obrazec prikazan.
  • Vse funkcionalnosti obrazca so opisane kot podrobnosti in ekipe. Podrobnosti so podatki, s katerimi deluje obrazec, ukazi pa so dejanja, ki jih je treba izvesti.
  • Obrazec deluje tako na strežniku kot na odjemalcu.
  • V kontekstu odjemalca skoraj vse vrste aplikacij niso na voljo, zato je nemogoče spremeniti podatke v informacijski bazi.
  • Za vsako metodo ali spremenljivko obrazca mora biti določena direktiva o kompilaciji, definiranje lokacije izvajanja (odjemalec ali strežnik) in dostop do konteksta obrazca.
Naštejmo direktive za prevajanje metod obrazca:
  • &OnClient
  • &Na strežniku
  • &Na strežniku brez konteksta
  • &OnClientOnServerWithout Context
Naj ponazorimo zgoraj navedeno. Posnetek zaslona prikazuje primer upravljanega obrazca in njegovega modula v razvojnem načinu. Poiščite deklarativni opis, rekvizite, direktive za prevajanje itd.

Vse nadaljnje razprave bodo o desni strani ilustracije, o tem, kako strukturirati kodo modula in katera načela vam bodo omogočila izvajanje učinkovite interakcije odjemalec-strežnik.

Opredelimo problem

Minilo je nekaj let, odkar se nova različica platforme 1C aktivno uporablja in tako 1C kot njegovi številni partnerji so izdali številne rešitve (konfiguracije).
Ali so razvijalci v tem času razvili skupno razumevanje načel interakcije med odjemalcem in strežnikom pri ustvarjanju obrazcev in ali se je pristop k implementaciji programskih modulov spremenil v novi arhitekturni realnosti?

Oglejmo si strukturo kode (modul oblike) v več oblikah iste standardne konfiguracije in poskusimo najti vzorce.
S strukturo mislimo na dele kode (najpogosteje so to bloki komentarjev), ki jih razvijalec dodeli metodam združevanja in direktivam prevajanja za te metode.
Primer 1:
Oddelek obdelovalcev dogodkov Metoda - na odjemalcu Metoda - na strežniku Metoda - na odjemalcu Oddelek servisnih postopkov in funkcij Funkcije pomožnega nadzora vnosa
Primer 2:
Storitveni postopki in funkcije Plačilni dokumenti Vrednosti Obdelovalci dogodkov
Primer 3:
Storitveni postopki na strežniku Storitveni postopki na odjemalcu Storitveni postopki na strežniku brez konteksta Obravnavalniki dogodkov glave Upravljalci dogodkov ukazov
Primer 4:
Postopki za splošne namene Upravljalniki dogodkov obrazcev Postopki podsistema »kontaktni podatki«.
V bistvu manjka struktura kode ali milo rečeno je podobna tisti, ki je bila v obrazcih 8.1:

  • Neinformativne besede "Splošno, Storitev, Pomožno".
  • Plahi poskusi ločevanja metod odjemalca in strežnika.
  • Metode so pogosto razvrščene po elementih vmesnika »Delo s tabelarnim delom Izdelki, Kontaktni podatki«.
  • Poljubna razporeditev metod in kodnih skupin. Na primer, obdelovalci dogodkov so lahko v eni obliki na vrhu, v drugi na dnu, v tretji sploh niso označeni itd.
  • In ne pozabimo, da je vse to znotraj ene konfiguracije.
  • Da, obstajajo konfiguracije, v katerih so besede "Splošno, Servis, Pomožni" vedno na istih mestih, vendar ...
Zakaj potrebujete strukturo kode?
  • Poenostavitev vzdrževanja.
  • Poenostavite učenje.
  • Beleženje splošnih/pomembnih/uspešnih načel.
  • ... tvoja možnost
Zakaj obstoječi razvojni standard iz 1C ne pomaga?
Oglejmo si načela, objavljena na diskih ITS in v različnih “Navodilih za razvijalce ...”, ki so priporočena pri pisanju upravljanega obrazca.
  • Zmanjšajte število klicev strežnika.
  • Maksimalno računalništvo na strežniku.
  • Nekontekstualni strežniški klici so hitrejši od kontekstualnih.
  • Program z mislijo na komunikacijo med odjemalcem in strežnikom.
  • itd.
To so slogani, ki popolnoma držijo, a kako jih uresničiti? Kako minimizirati število klicev, kaj pomeni programirati v načinu odjemalec-strežnik?

Oblikovalski vzorci ali generacijska modrost

Interakcija med odjemalcem in strežnikom se že desetletja uporablja v različnih programskih tehnologijah. Odgovor na vprašanja, opisana v prejšnjem razdelku, je že dolgo znan in je povzet v dveh osnovnih načelih.
  • Oddaljena fasada(v nadaljevanju vmesnik za oddaljeni dostop)
  • Objekt prenosa podatkov(v nadaljevanju predmet prenosa podatkov)
Beseda Martina Fowlerja, njegov opis teh načel:
  • … Vsak objekt, ki je potencialno namenjen oddaljenemu dostopu, mora imeti vmesnik z nizko zrnatostjo, kar bo zmanjšalo število klicev, potrebnih za izvedbo določenega postopka. ... Namesto da zahtevate račun in vse njegove postavke ločeno, morate prebrati in posodobiti vse postavke računa v eni zahtevi. To vpliva na celotno strukturo objekta ... Ne pozabite: vmesnik za oddaljeni dostop ne vsebuje domenske logike.
  • ...če bi bila skrbna mama, bi svojemu otroku zagotovo rekla: “Nikoli ne piši objektov za prenos podatkov!” V večini primerov predmeti za prenos podatkov niso nič drugega kot napihnjena terenska garnitura... Vrednost te gnusne pošasti je izključno v možnosti prenašanje več informacij po omrežju v enem klicu- tehnika, ki je zelo pomembna za porazdeljene sisteme.
Primeri predlog v platformi 1C
Vmesnik za programiranje aplikacij, ki je na voljo razvijalcu pri razvoju upravljanega obrazca, vsebuje veliko primerov teh načel.
Na primer, metoda OpenForm(), tipičen "grob" vmesnik.
OpeningParameters = Nova struktura ("Parameter1, Parameter2, Parameter3", Vrednost1, Vrednost2, Vrednost3); Obrazec = OdpriObrazec(ImeObrazca, Parametri odpiranja);
Primerjajte s slogom, sprejetim v v8.1.
Obrazec = GetForm(FormName); Form.Parameter1 = Vrednost1; Form.Parameter2 = Vrednost2; Form.Open();

V kontekstu upravljanega obrazca je veliko »predmetov prenosa podatkov«. Lahko izberete sistemski in definira razvijalec.
Sistemske modelirajo objekt aplikacije na odjemalcu, v obliki enega ali več podatkovnih elementov obrazca. Nemogoče jih je ustvariti brez sklicevanja na podrobnosti obrazca.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Pretvorba sistemskih objektov za prenos podatkov v vrste aplikacij in nazaj se izvede z naslednjimi metodami:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Pogosto se eksplicitna pretvorba uporablja pri prilagajanju obstoječe rešitve. Metode lahko pričakujejo (uporabljajo funkcije) vhodne parametre, kot je ValueTable in ne FormDataCollection, ali pa je bila metoda definirana v kontekstu predmeta aplikacije in je postala nedosegljiva za neposreden klic iz obrazca.
Primer 1C v8.1:
// na odjemalcu v kontekstu obrazca FillUserCache(DepartmentLink)
Primer 1C v8.2:
// na strežniku v kontekstu obrazca ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Objekti za prenos podatkov, katerih strukturo določi razvijalec, so majhna podmnožica vrst, ki so na voljo tako na odjemalcu kot na strežniku. Najpogosteje se kot parametri in rezultati metod "grobega" vmesnika uporabljajo:

  • Primitivni tipi (niz, število, logična vrednost)
  • Struktura
  • Dopisovanje
  • Array
  • Povezave do objektov aplikacije (enolični identifikator in predstavitev besedila)
Primer: metoda sprejme seznam naročil za spremembo statusa in odjemalcu vrne opis napak.
Funkcija &OnServerWithoutContext ServerChangeOrderStatus(Orders, NewStatus) Napake = Novo ujemanje(); // [naročilo][opis napake] Za vsako naročilo iz cikla naročil StartTransaction();

Poskusite DocOb = Order.GetObject();

…. druga dejanja, možna ne samo z naročilom... Izjema CancelTransaction();
  • Errors.Insert(Order, ErrorDescription()); EndAttempt;
  • EndCycle;
  • Napaka vrnitve; EndFunction // ServerChangeOrderStatus() Strukturiranje kode
  • Glavni cilji, ki naj bi jih odražal modul upravljanega obrazca, in pristopi k rešitvi. Jasno ločevanje kode odjemalca in strežnika.
Ne pozabimo, da sta v času izvajanja to dva medsebojno delujoča procesa, od katerih ima vsak bistveno drugačno razpoložljivo funkcionalnost.
  • Jasna identifikacija vmesnika za oddaljeni dostop, katere metode strežnika je mogoče priklicati od odjemalca in katere ne?
  • Imena metod oddaljenega vmesnika se začnejo s predpono "Server". To vam omogoča, da med branjem kode takoj vidite prenos nadzora na strežnik, in poenostavi uporabo kontekstualne pomoči. Upoštevajte, da uradno priporočilo (ITS) predlaga poimenovanje metod s postfiksi, na primer ChangeOrderStatusOnServer(). Vendar naj ponovimo, da vseh strežniških metod ni mogoče priklicati iz odjemalca, zato je bolj pomembna logična dostopnost kot lokacija prevajanja. Zato s predpono »Server« označimo samo metode, ki so na voljo odjemalcu; pokličimo primer metode ServerChangeOrderStatus().

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="Berljivost."/> // <Описание> // // /////////////////////////////////////////////// // /////////////////////////// // SPREMENLJIVKE MODULA ///////////////// // ///////////////////////////////////////////// //// ////////// // NA STREŽNIKU //******** DOGODKI NA STREŽNIKU ******* &Na strežniškem postopku, ko je ustvarjen na strežniku (napaka, standardna obdelava) / /Vstavite vsebino upravljalnika Konec postopka //******** VMESNIK ZA DALJINSKI DOSTOP ******* //******* POSLOVNA LOGIKA NA STREŽNIKU ******* ///////// ///////////////////////////////////////// /////// //////////////////// // SKUPNE METODE ODJEMALCA IN STREŽNIKA //////////////// /////// //////////////////////////////////////////// ///// //////// // NA STRANKI //******** POSLOVNA LOGIKA NA STRANKI ******* //******* EKIPA * ****** //******** DOGODKI STRANKE ******* /////////////////////////// ///// ///////////////////////////////////////////// // / / GLAVNI OPERATERJI PROGRAMA

Povezana vprašanja
Na koncu bomo opisali več področij, o katerih je koristno razmišljati pri programiranju interakcije med odjemalcem in strežnikom.
  • Možnosti implementacije vmesnika za oddaljeni dostop. Asinhronost, raven podrobnosti ...
  • Predpomnjenje. 1C je sprejel neuspešno arhitekturno odločitev, ki je uvedla predpomnjenje samo na ravni klicnih metod skupnih modulov in ni zagotovila nadzornih zmogljivosti (čas ustreznosti, ponastavitev na zahtevo).
  • Implicitni klici strežnika. Ne pozabite na tehnološke lastnosti; veliko "neškodljivih" operacij na odjemalcu povzroči, da platforma vzpostavi stik s strežnikom.


 

Morda bi bilo koristno prebrati: