1c verwaltetes Anwendungsmodul. Allgemeine Module. Flag „Serveraufruf“.

Drucken (Strg+P)

Objekte im Zweig „Allgemeine Module“ des Konfigurationsbaums sollen die Texte von Funktionen und Prozeduren enthalten, die von jedem anderen Konfigurationsmodul aufgerufen werden können.
AUFMERKSAMKEIT! Ein allgemeines Modul kann nur Prozedur- und Funktionsdefinitionen enthalten.
Prozeduren und Funktionen eines gemeinsamen Moduls, auf die in den Überschriften verwiesen wird Stichwort Der Export ist einer der Komponenten globaler Kontext. Weitere Informationen zum Schreiben von Prozeduren in einem allgemeinen Modul finden Sie in den Abschnitten „Format der Quelltexte von Programmmodulen“ und „Operatoren“ der integrierten Sprachhilfe.
Um ein allgemeines Modul zu bearbeiten, klicken Sie in der Eigenschaftenpalette eines Objekts vom Typ „Gemeinsame Module“ im Konfigurationsfenster in der Eigenschaft „Modul“ auf den Link „Öffnen“. Der Text des allgemeinen Moduls wird im Textbearbeitungsmodus des Softwaremoduls zur Bearbeitung im Texteditor des 1C:Enterprise-Systems ausgegeben.
Das gemeinsame Modul ist Teil der Konfiguration und wird nur als Teil der Konfiguration gespeichert.
Die Global-Eigenschaft bestimmt, ob die exportierten Methoden eines gemeinsamen Moduls Teil des globalen Kontexts sind.
Wenn die Global-Eigenschaft auf True gesetzt ist, stehen die exportierten Methoden des gemeinsamen Moduls als Methoden des globalen Kontexts zur Verfügung.
Wenn die Global-Eigenschaft auf False gesetzt ist, wird im globalen Kontext eine Eigenschaft mit einem Namen erstellt, der mit dem Namen des gemeinsamen Moduls in den Metadaten übereinstimmt. Diese Eigenschaft ist schreibgeschützt. Der Wert dieser Eigenschaft ist das GeneralModule-Objekt. Exportierte Methoden dieses gemeinsamen Moduls sind über dieses Objekt verfügbar. Somit sehen Zugriffsmethoden nicht globaler gemeinsam genutzter Module wie folgt aus: XXXXX.YYYYY, wobei XXXXX der Name der Eigenschaft ist, die dem Kontext des gemeinsam genutzten Moduls entspricht, und YYYYY der Name der exportierten Methode des gemeinsam genutzten Moduls ist.
Beispiel:

Arbeiten MIT Retail Equipment.ConnectBarcode Scanner();

Verschiedene Kontext- und gemeinsame Module

Mithilfe der Eigenschaften allgemeiner Module und Präprozessoranweisungen können Sie die Ausführung organisieren verschiedene Methoden gemeinsame Module im richtigen Kontext.
Jede Eigenschaft eines gemeinsamen Moduls ist für die Fähigkeit verantwortlich, das gemeinsame Modul in einem bestimmten Kontext zu kompilieren (und auszuführen).
Folgende Eigenschaften stehen zur Verfügung, die für den Kontext verantwortlich sind, in dem die Methoden des allgemeinen Moduls verfügbar sind:
● Kunde (reguläre Bewerbung)– Methoden des allgemeinen Moduls stehen für den Thick Client im Modus zur Verfügung regelmäßige Anwendung;
● – Methoden des allgemeinen Moduls werden für den Thin Client, Web Client sowie für den Thick Client verfügbar sein
verwalteter Anwendungsmodus;
● Server – Methoden des gemeinsamen Moduls sind auf dem Server verfügbar;
● Äußerer Join– Methoden des gemeinsamen Moduls werden in der äußeren Verbindung verfügbar sein.
Wenn mehrere Eigenschaften gleichzeitig gesetzt werden, bedeutet dies, dass die Methoden des gemeinsamen Moduls in mehreren Kontexten verfügbar sind.
Wenn ein gemeinsames Modul über die Eigenschaft „Server“ und andere Eigenschaften verfügt, bedeutet dies, dass das gemeinsame Modul gleichzeitig auf dem Server und im ausgewählten Client verfügbar ist. Es ist notwendig zu verstehen, dass es sich tatsächlich um mehrere Versionen des kompilierten Codes handelt (je nach Anzahl der ausgewählten Clients und des Servers selbst).
Wenn außerdem eine Methode, die sich in einem solchen gemeinsamen Modul befindet, von der Client-Seite aufgerufen wird, wird die Client-Kopie des gemeinsamen Moduls verwendet, und wenn vom Server, die Server-Kopie. In diesem Fall können Sie den Server mithilfe von Präprozessoranweisungen (weitere Einzelheiten finden Sie hier) vor Code „schützen“, der nicht auf ihm ausgeführt werden kann.
Schauen wir uns ein Beispiel an. Im gemeinsamen Modul (das auf dem Thin Client und auf dem Server ausgeführt werden kann) gibt es eine Methode, die sich auf der Thin Client-Seite und auf der Serverseite leicht unterschiedlich verhält. Mal sehen, wie das geht:

#Wenn ThinClient, dann
// Warnung anzeigen
ShowUserAlert(„Auf dem Kunden“);
#EndIf
Ende des Verfahrens
Dann sieht der Code auf der Serverseite so aus:
Verfahren CommonModule()-Methode Export
// Verschiedene wichtige Codes kommen hierher
Ende des Verfahrens
Und auf der Thin-Client-Seite sieht der Code so aus:
Prozedur CommonModule Method() Exportieren
// Verschiedene wichtige Codes kommen hierher
// Warnung anzeigen
ShowUserAlert(“Auf Client”);
Ende des Verfahrens

Es gibt mehrere Möglichkeiten, die Kontrolle vom Client auf den Server zu übertragen:
● Rufen Sie die Methode des gemeinsamen Servermoduls auf.
● Rufen Sie in einem Formular oder Befehlsmodul eine Methode auf, der Kompilierungsanweisungen vorangestellt sind &OnServer, &OnServerWithout Kontext

Gleichzeitig ist es nicht möglich, Methoden allgemeiner Clientmodule (die nicht über die Server-Eigenschaft verfügen) und Clientmethoden eines Formularmoduls oder Befehlsmoduls aus Serverprozeduren aufzurufen. Die Steuerung wird an den Client zurückgegeben, nachdem der Aufruf der äußersten Servermethode abgeschlossen ist.
Eine Ausnahme bilden die Methoden des Formularmoduls und des Befehlsmoduls, denen Kompilierungsanweisungen vorangestellt sind &OnClientOnServer, &OnClientOnServerWithout Context
Folgende Punkte sollten außerdem erwähnt werden:
● Wenn ein gemeinsames Modul für mehr als einen Client verfügbar ist, sollten Sie beim Schreiben von Programmcode die maximalen Einschränkungen berücksichtigen, die von Clients auferlegt werden können, oder Präprozessoranweisungen verwenden, um clientspezifischen Code zu „isolieren“.
● Präprozessoranweisungen sind auch dann sinnvoll, wenn ein gemeinsames Modul mehrere Ausführungskontexte hat, beispielsweise eine externe Verbindung und einen Thin Client oder (was viel häufiger vorkommt) einen Client und einen Server. In diesem Fall bilden die Präprozessoranweisungen einen Rahmen für interaktiven Code, der nicht auf dem Server, aber auf dem Client verwendet werden kann (siehe Beispiel oben).
Weitere Informationen zu Präprozessoranweisungen und Kompilierungsanweisungen finden Sie im Abschnitt „Ausführung von Prozeduren und Funktionen“ der eingebetteten Sprachhilfe.
Die Eigenschaft „Server aufrufen“ soll die Möglichkeit steuern, exportierte Methoden des allgemeinen Servermoduls aus Clientcode aufzurufen.
Wenn die Eigenschaft festgelegt ist, stehen die exportierten Methoden des Server-Common-Moduls für den Aufruf vom Client zur Verfügung. Wenn die Eigenschaft nicht festgelegt ist, können solche exportierten Methoden nur von serverseitigen Methoden aufgerufen werden (sowohl Methoden serverseitiger gemeinsamer Module als auch serverseitige Methoden von Formularmodulen und Befehlsmodulen).
Beratung . Es wird empfohlen, die Eigenschaft „Serveraufruf“ auf „False“ zu setzen, wenn das allgemeine Servermodul Methoden enthält, die Sie nicht vom Client aufrufen möchten (z. B. aus Sicherheitsgründen).
Notiz. Wenn die Eigenschaften gleichzeitig festgelegt werden Kunde (reguläre Bewerbung), Client (verwaltete Anwendung), Äußerer Join, dann wird die Eigenschaft „Server anrufen“ automatisch zurückgesetzt. Wenn die Eigenschaft „Server anrufen“ gesetzt ist, werden die Eigenschaften automatisch zurückgesetzt Kunde (reguläre Bewerbung), Client (verwaltete Anwendung) Und Äußerer Join, wenn diese Eigenschaften gleichzeitig festgelegt wurden.
Eigentum Privilegiert soll die Zugriffsrechtekontrolle beim Ausführen von Methoden eines gemeinsamen Moduls deaktivieren.
NOTIZ. Wenn die Immobilie Privilegiert installiert ist, wird die Servereigenschaft automatisch für das gemeinsame Modul festgelegt und die übrigen Eigenschaften werden zurückgesetzt ( Kunde (reguläre Bewerbung), Client (verwaltete Anwendung) und B externe Verbindung). Ein privilegiertes Shared-Modul kann nur auf dem Server ausgeführt werden.

Rückgabewerte wiederverwenden

Wenn das gemeinsam genutzte Modul nicht global ist, wird die Eigenschaft „Reuse Return Values“ verfügbar. Diese Eigenschaft kann die folgenden Werte annehmen:
● Nicht verwenden – Es gibt keine Wiederverwendung von Rückgabewerten für Funktionen in diesem gemeinsamen Modul.
● Pro Anruf und pro Sitzung – Das gemeinsam genutzte Modul verwendet eine Methode, um die Wiederverwendung von Daten zu bestimmen. Der Kern dieser Methode besteht darin, dass sich das System während der Codeausführung die Parameter und das Ergebnis der Funktionen nach dem ersten Aufruf der Funktion merkt. Wenn eine Funktion erneut mit denselben Parametern aufgerufen wird, wird der gespeicherte Wert (aus dem ersten Aufruf) zurückgegeben, ohne dass die Funktion selbst ausgeführt wird. Wenn eine Funktion während ihrer Ausführung die Werte von Parametern ändert, führt ein erneuter Aufruf der Funktion nicht dazu.
Die folgenden Funktionen zum Speichern von Anrufergebnissen können hervorgehoben werden:
● Wenn eine Funktion auf dem Server ausgeführt und vom Servercode aufgerufen wird, werden die Parameterwerte und das Ergebnis des Aufrufs für die aktuelle Sitzung auf der Serverseite gespeichert.
● Wenn die Funktion auf einem Thick- oder Thin-Client ausgeführt wird, werden die Werte der Parameter und Ergebnisse des Aufrufs auf der Client-Seite gespeichert.
● Wenn eine Funktion auf der Serverseite ausgeführt und vom Clientcode aufgerufen wird, werden die Werte der Aufrufparameter sowohl auf der Clientseite als auch auf der Serverseite (für die aktuelle Sitzung) gespeichert.
Gespeicherte Werte werden gelöscht:
● wenn die Eigenschaft auf „Für die Dauer des Anrufs“ eingestellt ist:
● auf der Serverseite – wenn die Kontrolle vom Server zurückgegeben wird;
● auf der Clientseite – wenn eine Prozedur oder Funktion der integrierten Sprache abgeschlossen ist Höchststufe(wird vom System über eine Schnittstelle aufgerufen und nicht über eine andere Prozedur oder integrierte Sprachfunktion);
● wenn die Eigenschaft des gemeinsam genutzten Moduls auf „Für die Dauer der Sitzung“ eingestellt ist:
● auf der Serverseite – am Ende der Sitzung;
● auf der Clientseite – beim Schließen der Clientanwendung.
Die gespeicherten Werte werden gelöscht:
● auf dem Server, im Thick Client, in der externen Verbindung, im Thin Client und im Web Client mit normaler Verbindungsgeschwindigkeit – 20 Minuten nach Berechnung des gespeicherten Werts oder 6 Minuten nach der letzten Nutzung;
● bei einem Thin Client und einem Web Client mit geringer Verbindungsgeschwindigkeit – 20 Minuten nach Berechnung des gespeicherten Werts;
● im Falle eines Mangels Arbeitsspeicher im Server-Workflow;
● beim Neustart des Workflows;
● wenn der Kunde zu einem anderen Workflow wechselt.
Nachdem die Werte entfernt wurden, erfolgt der Aufruf der exportierten Funktion wie beim ersten Aufruf.
Diese Eigenschaft allgemeiner Module hat keinen Einfluss auf die Ausführung von Prozeduren – Prozeduren werden immer ausgeführt.

Wenn ein allgemeines Modul so eingestellt ist, dass es Rückgabewerte wiederverwendet, gelten für die von der Funktion exportierten Parametertypen eine Reihe von Einschränkungen. Parametertypen können nur sein:
● Primitive Typen ( Undefiniert, NULL, Boolescher Wert, Zahl, Zeichenfolge, Datum).
● Alle Verweise auf Datenbankobjekte.
● Strukturen mit Eigenschaftswerten der oben genannten Typen. In diesem Fall wird die Identität der Parameter „durch den Inhalt“ der Strukturen gesteuert.
Wenn die exportierte Funktion ein Objekt zurückgibt, gibt sie tatsächlich einen Verweis auf das im Cache gespeicherte Objekt zurück. Wenn sich nach Erhalt dieser Referenz der Zustand des Objekts ändert, wird ein nachfolgender Aufruf derselben Funktion eine Referenz auf das bereits geänderte Objekt zurückgeben, ohne dass die Funktion tatsächlich ausgeführt wird. Dieses Verhalten bleibt bestehen, bis der gespeicherte Wert gelöscht wird (aus irgendeinem Grund). Mit anderen Worten: Die Änderung des Zustands eines Objekts, das aus einem Funktionsaufruf von einem gemeinsamen Modul mit Wiederverwendung von Rückgabewerten resultiert, ist nicht die Grundlage für den eigentlichen Funktionsaufruf. Sie sollten auch bedenken, dass der Cache der zurückgegebenen Objekte keine Rolle spielt
Status des privilegierten Modus zum Zeitpunkt des Funktionsaufrufs unter Wiederverwendung von Rückgabewerten. Diese Funktion kann zu folgendem Verhalten führen:
● Die eigentliche Ausführung des Funktionsaufrufs mit Wiederverwendung von Rückgabewerten (der erste Aufruf) wurde mit aktiviertem privilegierten Modus durchgeführt.
● Beim Ausführen einer Funktion wurde ein Objekt empfangen, das bei deaktiviertem privilegierten Modus nicht empfangen werden kann.
● Nachfolgende Aufrufe der Funktion wurden ausgeführt, ohne dass der privilegierte Modus festgelegt wurde.
● Bis jedoch der Rückgabeobjekt-Cache geleert wird oder der eigentliche Aufruf erneut erfolgt, gibt die Funktion ein formal unzugängliches Objekt zurück.
● Das umgekehrte Verhalten gilt auch, wenn der erste Aufruf ohne Einstellung des privilegierten Modus erfolgt und im privilegierten Modus ein Objekt, das im privilegierten Modus hätte empfangen werden können, nicht zurückgegeben wird.

Wenn ein gemeinsames Modul die Eigenschaft hat Rückgabewerte wiederverwenden auf gesetzt ist. Für die Dauer der Sitzung können Werte des Typs nicht in den von Funktionen eines solchen Moduls zurückgegebenen Werten verwendet werden Stundenplan-Manager.
Wenn eine Funktion eines gemeinsam genutzten Moduls mit festgelegter Wiederverwendbarkeit aus demselben gemeinsam genutzten Modul (z. B. mit dem Namen „GeneralModule“) aufgerufen wird, sollte die folgende Einschränkung beachtet werden: Wenn die Funktion mit dem Namen MyFunction() aufgerufen wird, Dann wird die Funktion jedes Mal ausgeführt, wenn die Funktion aufgerufen wird. Damit die gespeicherten Werte verwendet werden können, muss die Funktion mit ihrem vollständigen Namen aufgerufen werden:
GeneralModule.MyFunction().
Die globale Kontextmethode entfernt alle wiederverwendeten Werte, sowohl serverseitig als auch clientseitig, unabhängig davon, wo die Methode aufgerufen wird. Nach Ausführung der Methode UpdateReusedValues() Der erste Funktionsaufruf wird vollständig ausgeführt.

1.1. Gemeinsame Module werden erstellt, um Verfahren und Funktionen zu implementieren, die nach bestimmten Merkmalen zusammengefasst sind. In der Regel werden Verfahren und Funktionen eines Konfigurationssubsystems (Verkauf, Beschaffung) oder Verfahren und Funktionen eines ähnlichen Konfigurationssubsystems in einem gemeinsamen Modul zusammengefasst. funktionaler Zweck(Arbeiten mit Saiten, allgemeiner Zweck).

1.2. Bei der Entwicklung gemeinsam genutzter Module sollten Sie einen von vier Codeausführungskontexten wählen:

	Gemeinsamer Modultyp	Beispiel für einen Namen	Serveraufruf	Server	Äußerer Join	Klient (reguläre Bewerbung)	Klient (verwaltete Anwendung)
1.	Server	General Purpose (oder General Purpose Server)
2.	Server, der vom Client aufgerufen werden soll	GeneralPurposeCallServer
3.	Klient	General Purpose Client (oder General Purpose Global)
4.	Kundenserver	Allgemeiner ZweckClientServer

2.1. Gemeinsame Servermodule sind dazu gedacht, Serverprozeduren und -funktionen zu hosten, die nicht für die Verwendung durch Clientcode verfügbar sind. Sie implementieren die gesamte serverinterne Geschäftslogik der Anwendung.
Für den korrekten Betrieb der Konfiguration im externen Verbindungs-, verwalteten und regulären Anwendungsmodus sollten Serverprozeduren und -funktionen in gemeinsamen Modulen mit den folgenden Merkmalen untergebracht werden:

• Server(Kontrollkästchen Serveraufruf zurücksetzen),
• Kunde (reguläre Bewerbung),
• Äußerer Join.

In diesem Fall ist die Möglichkeit gewährleistet, Serverprozeduren und -funktionen mit Parametern veränderlicher Typen aufzurufen (z. B. DirectoryObject, DocumentObject usw.). Typischerweise ist dies:

• Handler für Abonnements von Ereignissen von Dokumenten, Verzeichnissen usw., die einen veränderlichen Wert (Objekt) als Parameter annehmen.
• Serverprozeduren und -funktionen, an die ein Objekt als Parameter von Modulen von Verzeichnissen, Dokumenten usw. sowie von Modulen mit Ereignisabonnements übergeben wird.

Serverseitige gemeinsam genutzte Module werden nach allgemeinen Regeln für die Benennung von Metadatenobjekten benannt.
Zum Beispiel: Arbeiten mit Dateien, Allgemeiner Zweck

In einigen Fällen kann ein Postfix hinzugefügt werden, um Namenskonflikte mit globalen Kontexteigenschaften zu verhindern "Server".
Zum Beispiel: RoutineTasksServer, DatenaustauschServer.

2.2. Gemeinsame Servermodule zum Aufrufen vom Client enthalten Serverprozeduren und -funktionen, die vom Clientcode aus verwendet werden können. Sie bilden die Client-Programmierschnittstelle des Anwendungsservers.
Solche Prozeduren und Funktionen sind in gemeinsamen Modulen mit folgender Funktion untergebracht:

• Server(Kontrollkästchen Serveraufruf Eingerichtet)

Serverseitige gemeinsame Module zum Aufruf von einem Client werden nach den allgemeinen Regeln für die Benennung von Metadatenobjekten benannt und müssen mit einem Postfix benannt werden „CallServer“.
Zum Beispiel: Arbeiten mit FilesCalling Server

Bitte beachten Sie, dass Exportprozeduren und -funktionen in solchen gemeinsam genutzten Modulen keine Parameter veränderlicher Typen enthalten dürfen ( DirectoryObject, DocumentObject usw.), da ihre Übertragung vom (oder zum) Client-Code nicht möglich ist.

Siehe auch:Einschränkung beim Setzen des „Server Call“-Flags für gemeinsame Module

2.3. Gemeinsame Client-Module enthalten Client-Geschäftslogik (nur für den Client definierte Funktionalität) und weisen die folgenden Merkmale auf:

• Client (verwaltete Anwendung))
• Kunde (reguläre Bewerbung)

Die Ausnahme besteht darin, dass Clientprozeduren und -funktionen nur im verwalteten Anwendungsmodus verfügbar sein dürfen (nur im regulären Anwendungsmodus oder nur im externen Verbindungsmodus). In solchen Fällen ist eine andere Kombination dieser beiden Merkmale akzeptabel.

Gemeinsame Clientmodule werden mit einem Postfix benannt "Klient".
Zum Beispiel: Arbeiten mit FilesClient, Allzweck-Client

Siehe auch: Minimieren des auf dem Client ausgeführten Codes

2.4. In einigen Fällen ist es zulässig, gemeinsame Client-Server-Module mit Prozeduren und Funktionen zu erstellen, deren Inhalt sowohl auf dem Server als auch auf dem Client gleich ist. Solche Prozeduren und Funktionen werden in gemeinsamen Modulen mit den folgenden Merkmalen untergebracht:

• Client (verwaltete Anwendung)
• Server(Kontrollkästchen Serveraufruf zurücksetzen)
• Kunde (reguläre Bewerbung)
• Äußerer Join

Gängige Module dieses Typs werden mit dem Postfix benannt "Kundenserver".
Zum Beispiel: Arbeiten mit FilesClient, Allgemeiner ZweckClientServer

Im Allgemeinen wird nicht empfohlen, gemeinsame Module sowohl für den Server als auch für den Client (verwaltete Anwendung) zu definieren. Es wird empfohlen, die für den Client und den Server definierten Funktionen in verschiedenen gemeinsamen Modulen zu implementieren – siehe Abschnitte. 2.1 und 2.3. Diese explizite Trennung der Client- und Server-Geschäftslogik wird durch Überlegungen zur Erhöhung der Modularität der Anwendungslösung, zur Vereinfachung der Entwicklerkontrolle über die Client-Server-Interaktion und zur Reduzierung des Fehlerrisikos aufgrund grundlegender Unterschiede in den Anforderungen für die Entwicklung von Client und Server diktiert Code (die Notwendigkeit, den auf dem Client ausgeführten Code zu minimieren, unterschiedliche Verfügbarkeit von Objekten und Plattformtypen usw.). In diesem Fall müssen Sie die unvermeidliche Erhöhung der Anzahl gemeinsamer Module in der Konfiguration berücksichtigen.

Ein Sonderfall gemischter Client-Server-Module sind Formular- und Befehlsmodule, die speziell darauf ausgelegt sind, Server- und Client-Geschäftslogik in einem Modul zu implementieren.

3.1. Es wird empfohlen, dass die Namen gemeinsamer Module den allgemeinen Regeln für die Benennung von Metadatenobjekten folgen. Der Name des allgemeinen Moduls muss mit dem Namen des Subsystems oder separaten Mechanismus übereinstimmen, dessen Prozeduren und Funktionen es implementiert. Es wird empfohlen, allgemeine Wörter wie „Prozeduren“, „Funktionen“, „Handler“, „Modul“, „Funktionalität“ usw. in den Namen allgemeiner Module zu vermeiden. und verwenden Sie sie nur in Ausnahmefällen, wenn sie den Zweck des Moduls besser verdeutlichen.

Um zwischen gemeinsamen Modulen eines Subsystems zu unterscheiden, die zur Implementierung von Prozeduren und Funktionen erstellt werden, die in verschiedenen Kontexten ausgeführt werden, wird empfohlen, ihnen die zuvor in den Absätzen beschriebenen Postfixe zu geben. 2.1-2.4.

Hallo zusammen.
Heute schauen wir uns an Module der 1C Enterprise 8.2-Plattform, davon gibt es mehr als in Version 8.1 und manchmal ist es nicht so einfach, es herauszufinden.
Beispiel:

Wenn Sie sich die 1C-Hilfe ansehen, sehen Sie die folgende Definition des Moduls:
Ein Modul ist ein Programm, das in der integrierten Sprache des 1C:Enterprise-Systems geschrieben ist.

Und um es einfach auszudrücken: B 1C-Module enthält ausführbaren Code, der notwendig ist, um irgendwie auf die Aktionen des Systems oder Benutzers zu reagieren, wenn visuelle Mittel nicht ausreichen, um die Interaktion von Objekten im Konfigurator zu beschreiben. Sie können Ihre eigenen Methoden auch in Programmmodulen beschreiben.

Jede Codezeile befindet sich in einem Modul, im Gegensatz zu 1C7.7, wo sich der Programmcode in den Zellen der Layouttabellen und in den Eigenschaften von Formularelementen befinden konnte.

Lassen Sie uns die Module auflisten, die in 1C 8.2 enthalten sind

Plattformmodule 1C Enterprise 8.2:

Verwaltetes Anwendungsmodul
Regelmäßiges Bewerbungsmodul
Externes Verbindungsmodul
Sitzungsmodul
Gemeinsame Module
Objektmodul
Formularmodul
Objektmanagermodul
Modul „Value Manager“.
Recordset-Module

Hauptabschnitte des Moduls:
1. Abschnitt zur Beschreibung lokaler Variablen dieses Moduls, Sie können eine Kompilierungsanweisung angeben (existiert nicht für alle Module).
2. Abschnitt zur Beschreibung von Verfahren und Funktionen. Wenn Sie keine Kompilierungsanweisung schreiben, ist sie standardmäßig &OnServer. Die Reihenfolge der Prozeduren und Funktionen spielt überhaupt keine Rolle.
3. Abschnitt des Hauptprogramms des Moduls (enthält einige Anweisungen). Dieser Abschnitt wird beim Zugriff auf ein Modul ausgeführt (existiert nicht für alle Module).

Nicht alle Module enthalten Variablenbeschreibungsabschnitte und einen Hauptprogrammabschnitt.
Zum Beispiel: Allgemeines Modul oder Sitzungsmodul.

Regeln für die Modulkompilierung:
1. Einige Module werden vollständig entweder auf der Client-Seite oder auf der Server-Seite kompiliert. Alle darin enthaltenen Methoden sind entweder Client- oder Servermethoden. Ein Beispiel für ein Clientmodul ist ein verwaltetes Anwendungsmodul.
2. Einige Module können Client- und Servermethoden kombinieren. In diesem Fall müssen für jede Methode Kompilierungsanweisungen angegeben werden – &OnClient oder &OnServer. Ein Beispiel sind verwaltete Formularmodule.

Moduleinteilung:
1. Server. Wird nur auf der Serverseite kompiliert – Objektmodul, Managermodul, Recordset-Modul.
2. Kunde. Wird nur auf dem Client kompiliert, z. B. ein verwaltetes Anwendungsmodul.
3. Kombiniert. Kann sowohl auf dem Server als auch auf dem Client kompiliert werden – das Formularmodul und allgemeine Module.

Speicherort der Modulkompilierung:
1. Thin Client (Bietet die Möglichkeit, einen Webbrowser zu verwenden).
2. Server.
3. Fetter Kunde.

Wie Sie sehen, gibt es nicht so wenige Module; fast jedes Konfigurationsobjekt verfügt über ein Modul, das seinen eigenen Zweck erfüllt.

Der Zweck jedes 1C 8.2-Moduls

Bewachen: Denken Sie über den Kauf von 1C Enterprise nach und wissen nicht, von wem? Das LBS-Unternehmen gehört zu den Top 20 1C: Franchisenehmern. Beschäftigt sich mit der Buchhaltungsautomatisierung auf Basis von 1C-Produkten. Kaufen Sie 1C-Produkte bei LBS und erhalten Sie hochwertigen 1C-Support und Service.

P.S. Lache über den Witz von Lukaschenko))

Fast alle Konfigurationsobjekte verfügen über ein Managermodul und für die meisten Objekte über ein Objektmodul. Programmieranfänger verstehen oft nicht die Unterschiede im Zweck dieser beiden Module.

Wenn Sie den Unterschied in ihrem Zweck verstehen, können Sie Programmcode schreiben, dessen Struktur korrekter ist, und in einigen Fällen 1C-Serverressourcen sparen und die Leistung der Anwendungslösung steigern.

In diesem Artikel beleuchten wir die grundlegenden Unterschiede zwischen diesen Modulen sowohl aus theoretischer Sicht als auch anhand eines konkreten Praxisbeispiels.

Theorie

Wenden wir uns den Grundlagen der objektorientierten Programmierung (OOP) zu und ziehen wir eine Analogie zu unserem Beispiel. In OOP können Methoden für Objekte unterteilt werden in statisch und einfach. Einfache Methoden kann nur für ein bestimmtes Objekt aufgerufen werden, auf das wir im aktuellen Codekontext Zugriff haben. Statische Methoden haben keinen direkten Zugriff auf Objektdaten. Um auf ein Objekt zuzugreifen, müssen Sie zunächst eine Instanz davon erstellen. Gleiches gilt für die 1C:Enterprise 8.x-Plattform.

Im Objektmodul speichert die Plattform Prozeduren und Funktionen, die nur beim Arbeiten mit einem bestimmten Objekt aufgerufen werden können, beispielsweise mit dem Objekt des Verzeichniselements „Nomenklatur“. Das Managermodul enthält Prozeduren und Funktionen, die auf alle Objekte angewendet werden können dieser Art, aber mit der ersten Erstellung einer Instanz dieses Objekts. Das heißt, um ein Nomenklaturelement aus diesem Modul zu ändern, führen Sie zunächst die Methode „GetObject()“ aus, um auf das Element zu verweisen, und arbeiten Sie dann damit.

Kommen wir von der Theorie zur Praxis.

Üben

Kommen wir zu einem praktischen Beispiel. Nehmen wir an, wir müssen das Problem des Druckens einer Produktliste lösen. Der Benutzer druckt ein Produkt entweder direkt aus einem Verzeichniselement oder aus dem Produktlistenformular. Betrachten wir zwei Möglichkeiten, die Aufgabe abzuschließen.

Druckvorgang im Objektmodul

Fügen Sie im Verzeichnisobjektmodul die folgende Funktion hinzu:

// Einen Verweis auf ein Verzeichniselement an die Funktion übergeben Funktion PrintSelectedProducts(Link) Export TabDoc = New TabularDocument; Layout = Verzeichnisse. Waren. GetLayout("Layout"); Anfrage = Neue Anfrage; Anfrage. Text = " AUSWÄHLEN | Produkte . Präsentation als Produkt,| Waren . MarkDeletion,| Waren . Herstellerkürzel |AUS| Verzeichnis . Produkte AS-Produkte|WO | Waren . Link B(&Produktarray)" ; Request. SetParameter(" Array of Products ", Link); //Nach Link auswählen

Der Programmcode wird vollständig vom Druckdesigner generiert. Bemerkenswert ist lediglich die Anzeige mit Verweis auf das Verzeichniselement „Produkte“ in der Anfrage. Die Referenz wird als Parameter an die Funktion übergeben. Als Ergebnis des Aufrufs der Funktion wird „PrintSelectedProducts“ zurückgegeben Tabellenkalkulationsdokument mit einer abgeschlossenen Produktposition.

Der Programmcode zum Aufruf der Objektmethode „PrintSelectedProducts“ über den Formularbefehl „Print“ ist im folgenden Listing dargestellt:

&OnClient-Prozedurdruck (Befehl) // Kontakt Serverprozedur um das generierte Tabellendokument zu erhalten TabDoc = PrintServer(); // Zeigt das generierte Tabellendokument an TabDoc. Zeigen() ; EndProcedure & OnServer-Funktion PrintServer() // Konvertieren Sie das Formularobjekt in ein Verzeichnisobjekt „Produkte“, um eine Funktion aus dem Objektmodul aufzurufen ObjectItem = FormAttributeValue("Object" ); // Rufen Sie die Objektmodulprozedur auf und übergeben Sie dort einen Link zum aktuellen Verzeichniselement. Ergebnis // zurück zur Clientseite Gibt ObjectProduct zurück. PrintSelectedProducts(Object.Link) ; EndFunction

Daher haben wir das aktuelle Verzeichniselement gedruckt, indem wir mit seinem Objekt gearbeitet haben. Die Aufgabe bestand jedoch darin, eine Liste von Produkten auszudrucken, die der Benutzer selbst auswählen muss. Bei der Arbeit mit einem Objekt ist es nicht möglich, dem Benutzer auf einfache Weise eine solche Möglichkeit zu geben. Der korrekteste Weg wäre, aus der Artikelliste im Verzeichnis „Produkte“ zu drucken.

Druckvorgang im Manager-Modul

Fügen wir dem Verzeichnismanagermodul die folgende Exportprozedur hinzu:

// Übergeben Sie ein Array von Links zu Produkten Funktion PrintSelectedProducts(ArrayProducts) Export TabDoc = New TabularDocument; Layout = Verzeichnisse. Waren. GetLayout("Layout"); Anfrage = Neue Anfrage; Anfrage. Text = " AUSWÄHLEN | Produkte . Präsentation als Produkt,| Waren . MarkDeletion,| Waren . Herstellerkürzel |AUS| Verzeichnis . Produkte AS-Produkte|WO | Waren . Link B(&Produktarray)" ; Request. SetParameter(" Array of Products ", Array of Products) ; // Auswahl nach Array festlegen Ergebnis = Anfrage. Laufen(); HeaderArea = Layout. GetArea("Titel"); AreaFooter = Layout. GetArea(" Basement "); TableHeadArea = Layout. GetArea("Tabellenkopf"); TableFooterArea = Layout. GetArea("TableFooter"); DetailRecordsArea = Layout . GetArea("Details"); TabDoc. Klar() ; TabDoc. Ausgabe(Bereichstitel) ; TabDoc. Ausgabe(TableHeadArea); TabDoc. StartAutoGroupingRows() ; SelectionDetailRecords = Ergebnis. Wählen() ; Während SelectionDetailedRecords. Next() LoopDetailRecordArea. Optionen. Fill(SelectionDetailRecords) ; TabDoc. Output(DetailedRecordsArea, DetailedRecordsSelection.Level()) ; EndCycle ; TabDoc. FinishAutoGroupingRows() ; TabDoc. Ausgabe(TableFooterArea); TabDoc. Output(AreaFootground) ; TabDoc zurückgeben; EndFunction

Der Hauptunterschied zu einer Funktion in einem Objektmodul ist der Funktionsparameter. Als Parameter wird nun ein Array mit Links zu Produkten übergeben, die gedruckt werden sollen.

Der Programmcode des Formularbefehlsmoduls „Drucken“ sieht folgendermaßen aus:

& Auf der Client-Prozedur Print(Command) TabDoc = PrintServer() ; TabDoc. Zeigen() ; EndProcedure & OnServer-Funktion PrintServer() // Übergeben Sie ein Array von Links ausgewählter Produkte in der Verzeichnisliste // in die Manager-Modulfunktion „PrintSelectedProducts“ Rückgabeverzeichnisse. Waren. PrintSelectedItems(Items.List.SelectedRows) ; EndFunction

In diesem Fall sieht die Ausführung des Befehls im 1C:Enterprise-Modus wie folgt aus:

Wenn wir die Methode aus dem Manager-Modul verwenden, können wir auf die Daten im Verzeichnis „Produkte“ zugreifen, ohne für jeden Link ein Objekt zu erhalten. Da das Abrufen eines Objekts das Abrufen aller Daten aus der Datenbank für ein Verzeichniselement und das Platzieren der empfangenen Daten im RAM bedeutet, wirkt sich die Implementierung der Aufgabe auf die zweite Art positiv auf die Leistung aus. Schließlich nutzen wir in diesem Fall ein Minimum an Ressourcen (RAM) der Servermaschine.

Was verwenden?

Wie immer kommt es auf die konkrete Aufgabe an. Wenn Sie ein Dokument drucken müssen, dann mehr Beste Option- Verwenden Sie das Manager-Modul. Wenn Sie ein Objekt beispielsweise durch externe Verarbeitung tabellarischer Füllteile füllen müssen, ist es in diesem Fall besser, Prozeduren und Funktionen im Objektmodul zu platzieren, da diese speziell mit dem Objekt arbeiten.

In der Standardkonfiguration von „Trade Management“ Version 11 wird das Manager-Modul überall zum Drucken von Dokumenten verwendet. Schaut man sich die Konfiguration „Manufacturing Enterprise Management“ an, wird das Manager-Modul praktisch nicht verwendet, da die Konfiguration in älteren Versionen der Plattform geschrieben wurde, in denen es keine vollständige Unterstützung für diesen Mechanismus gab.

Konfiguration mit Beispielen aus dem Artikel.