Plattformmodule 1C:Enterprise 8.3, 8.2

Gemeinsame Module

Funktionen, die in einem solchen Modul mit dem Flag „export“ deklariert sind, können von überall in der Konfiguration aufgerufen werden. Der Aufruf erfolgt über CommonModuleName.FunctionName().

Solche Module haben keinen variablen Abschnitt.

Die Ausführung allgemeiner Module hängt von den Einstellungen in ihren Eigenschaften ab:

Flagge „Global“

Wenn dieses Flag gesetzt ist, wird der Kontext eines solchen Moduls global. Das heißt, wenn Sie auf die Exportfunktionen zugreifen, müssen Sie den Modulnamen nicht angeben. Die Namen seiner Exportfunktionen müssen jedoch innerhalb des globalen Konfigurationskontexts eindeutig sein.

Server-Flag

Die Funktionen eines solchen Moduls können auf dem Server ausgeführt werden.

Flag „Client (reguläre Anwendung)“.

Die Funktionen eines solchen Moduls können im normalen Anwendungsmodus auf dem Client ausgeführt werden.

Flag „Client (verwaltete Anwendung)“.

Die Funktionen eines solchen Moduls können im verwalteten Anwendungsmodus auf dem Client ausgeführt werden.

Flag „Serveraufruf“.

Das Flag ist für Module verfügbar, bei denen das Flag „Server“ gesetzt ist. Ermöglicht dem Client, die Exportfunktionen dieses Moduls aufzurufen (die auf dem Server ausgeführt werden).

Externes Join-Flag

Die Exportfunktionen eines solchen Moduls können bei der Verbindung von einer externen Quelle aufgerufen werden.

Flagge „Privilegiert“

In einem Modul mit diesem Flag wird die Rechteprüfung deaktiviert. Geeignet für Produktivität oder Verwaltungstätigkeiten.

Wiederverwendungsoption

Wenn Sie diese Option aktivieren, werden die Rückgabewerte von Exportfunktionen sofort nach dem ersten Aufruf zwischengespeichert. Das Caching ist für die Dauer des Aufrufs (die Ausführungszeit einer bestimmten Prozedur) oder für die Dauer der Benutzersitzung möglich.

Anwendungsmodul

Entwickelt, um Anwendungsstart- und -beendigungsereignisse zu verarbeiten. Es gibt zwei Typen: für reguläre und verwaltete Anwendungen.

Sie sollten es nicht überlasten, da dies Auswirkungen auf die Startzeit der Anwendung hat.

Sitzungsmodul

Ein spezielles Modul, das zum Initialisieren von Sitzungsparametern verwendet wird. Dies ist notwendig, um den Code in verschiedenen Anwendungsmodulen nicht zu duplizieren.

Es sollte mit Vorsicht verwendet werden, da das Modul mehrmals ausgeführt werden kann und auch ohne weiteren Start der Datenbank ausgeführt werden kann. Wird vor Anwendungsmodulen ausgeführt.

Mit freundlichen Grüßen (Lehrer und Entwickler).

Guten Tag.
In diesem Beitrag befassen wir uns mit dem Anwendungsmodul, seinem Zweck und dem Ort der Kompilierung.

1C-Anwendungsmodul soll hauptsächlich den Moment erfassen, in dem die Anwendung gestartet und beendet wird.
Hier gibt es auch Handler, mit denen Sie ein externes Ereignis vom Gerät abfangen können.

Ereignisse für verwaltete Anwendungsmodule werden ausgelöst, wenn der Thin Client, Web Client und Thick Client einer verwalteten Anwendung gestartet werden.
Das verwaltete Anwendungsmodul überwacht den interaktiven Systemstart.

Das verwaltete Anwendungsmodul enthält:
Abschnitt zur Variablendeklaration
Abschnitt zur Verfahrens- und Funktionsbeschreibung
Hauptprogrammteil
Prozeduren, Funktionen und Variablen eines verwalteten Moduls können als Export (zugänglich außerhalb des jeweiligen Moduls) beschrieben werden. Dieses Modul kann auch spezielle Event-Handler enthalten, die unter bestimmten Umständen auftreten.

Schauen wir uns die Liste der Handler an, die durch Drücken von ( aufgerufen werden können) Strg+Alt+P).
Vor dem Systemstart – die Aktion ist noch nicht erfolgt (1C Enterprise 8.2 wird gestartet, aber die Anwendung selbst ist noch nicht auf dem Bildschirm erschienen). Wenn der Parameter „Failure“ auf „True“ gesetzt ist, startet die Anwendung einfach nicht. Wenn das System startet, ist die Aktion bereits abgeschlossen (es gibt keinen „Fehler“-Parameter). Vor dem Herunterfahren des Systems – die Anwendung ist noch nicht verschwunden (es gibt einen „Fehler“-Parameter).
Beim Herunterfahren des Systems wurde das interaktive Fenster bereits geschlossen.

Werfen Sie einen Blick auf den Syntaxassistenten und erfahren Sie mehr über verwaltete und regelmäßige Anwendungsereignisse.

Das Anwendungsmodul wird immer vollständig clientseitig kompiliert. Diese. Von dort aus können wir auf Serverprozeduren und Funktionen allgemeiner Module zugreifen und können nicht auf Konfigurationsobjekte wie Dokumente und Verzeichnisse zugreifen.
Beim Systemstart wird das verwaltete Anwendungsmodul kompiliert und je mehr Exportprozeduren und Funktionen darin deklariert werden, desto länger dauert der Systemstart.

Regelmäßiges Bewerbungsmodul

Das reguläre Anwendungsmodul ist an derselben Stelle zu sehen wie das verwaltete Anwendungsmodul. Wenn es jedoch nicht sichtbar ist, wählen Sie in den Konfiguratorparametern auf der Registerkarte „Allgemein“ die Option „Konfiguration für Startmodi bearbeiten“ für „Verwaltet“. „Anwendung“ und „Normalanwendung“ positionieren.
Wie das geht, erfahren Sie im Artikel:.

Regelmäßige Anwendungsmodulereignisse werden ausgelöst, wenn der Thick Client der regulären Anwendung gestartet wird.
Alles, was für das verwaltete Anwendungsmodul gesagt wurde, gilt auch für das reguläre Anwendungsmodul.

Ereignisse vor... und während....

Der Unterschied zwischen den Verfahren vor dem Start des Systembetriebs (Fehler) und beim Start des Systembetriebs ()

Bevor das System den Betrieb aufnimmt (Ablehnung) – die Aktion ist noch nicht abgeschlossen und wir können die Ausführung verweigern.
AtSystemStart() – die Aktion wurde bereits abgeschlossen und wir können den Start oder das Beenden der Anwendung nicht verweigern.

Das ist alles, vielen Dank für Ihre Aufmerksamkeit.

Bitte hinterlassen Sie Kommentare, Ihre Meinung ist mir wichtig.

Bewachen: Registrierung ärztlicher Atteste in 10 Minuten. Um ein Zertifikat von der staatlichen Verkehrssicherheitsinspektion zu erhalten, müssen Sie ein paar Tage aufwenden, es besteht jedoch die Möglichkeit, ein Zertifikat für eine Lizenz zu kaufen. Es ist möglich, ein Zertifikat auszuhändigen und zusätzlich eine Kopie der Lizenzen beizufügen

P.S. Und ich mag Jamala – You’re Made of Love

Verwaltetes Anwendungsmodul

Entwickelt hauptsächlich, um den Moment zu erfassen, in dem die Anwendung gestartet und beendet wird. Hier gibt es auch Handler, mit denen Sie ein externes Ereignis vom Gerät abfangen können. Im verwalteten Anwendungsmodul wird der interaktive Hochlauf des Systems überwacht.

Ereignisse für verwaltete Anwendungsmodule werden ausgelöst, wenn der Thin Client, Web Client und Thick Client der verwalteten Anwendung gestartet werden. Im Steuermodul Auf Anwendungen kann über die Eigenschaftenpalette des Stammkonfigurationsknotens oder über das Kontextmenü zugegriffen werden, das auf dem Stammkonfigurationsknoten aufgerufen wird.

Regelmäßiges Bewerbungsmodul

Das reguläre Anwendungsmodul spielt die gleiche Rolle wie das verwaltete Anwendungsmodul, nur die Ereignisse des regulären Anwendungsmoduls werden ausgelöst, wenn der Thick Client der regulären Anwendung gestartet wird.

Das reguläre Anwendungsmodul wird in der Eigenschaftenpalette des Stammkonfigurationsknotens verfügbar, nachdem die Option „Konfiguration für Startmodi bearbeiten“ in den Konfiguratorparametern auf der Registerkarte „Allgemein“ auf „Verwaltete Anwendung und normal“ eingestellt wurde.

Externes Verbindungsmodul

Das externe Verbindungsmodul dient zur Verarbeitung des Anmeldeereignisses (nicht interaktiv, aber im COM-Verbindungsmodus) und der Abmeldung. Es gibt entsprechende Handler. Bei einer COM-Verbindung öffnet sich kein interaktives Fenster, sodass Funktionen zum Dialog mit dem Benutzer nicht funktionieren. Es ist möglich, Exportvariablen und -methoden im Modul zu beschreiben. Das externe Verbindungsmodul wird auf dem Server kompiliert. Diese. Es ist möglich, auf die entsprechenden Konfigurationsobjekte, beispielsweise Verzeichnisse, zuzugreifen.

Sitzungsmodul

Es gibt ein so allgemeines Konfigurationsobjekt wie „Sitzungsparameter“. Das Sitzungsmodul wird erstellt, um Sitzungsparameter zu initialisieren (hierfür gibt es ein spezielles Ereignis; wenn die Anwendung gestartet wird, wird sie zuerst gestartet).

Läuft im privilegierten Modus (Zugriffsrechte werden beim Zugriff auf die Datenbank nicht überprüft). Das Sitzungsmodul wird auf dem Server kompiliert. Es gibt keinen Abschnitt zur Beschreibung von Variablen und einen Abschnitt für das Hauptprogramm; Exportmethoden können nicht beschrieben werden; er wird nur zum Festlegen von Sitzungsparametern verwendet. Wie Sie sehen, hat das Sitzungsmodul einen sehr engen Zweck.

Gemeinsame Module

Gemeinsame Module beschreiben einige gängige Algorithmen und enthalten Funktionen, die von verschiedenen Stellen aus aufgerufen werden können. Gemeinsame Module können sowohl auf dem Client als auch auf dem Server kompiliert werden.

In allgemeinen Modulen ist NUR der Abschnitt verfügbar, der Prozeduren und Funktionen beschreibt. Wenn Sie eine globale Variable verwenden müssen, können Sie entweder Sitzungsparameter oder eine Exportvariable eines verwalteten Anwendungsmoduls verwenden.

Im allgemeinen Modul können Sie einige Parameter festlegen, die sich auf das Verhalten auswirken. Wenn im allgemeinen Modul das Kontrollkästchen „Global“ aktiviert ist, sind dessen Exportfunktionen an der Bildung des globalen Kontexts beteiligt. Und auf sie kann direkt aus einem anderen Kontext zugegriffen werden (ohne den Namen des gemeinsamen Moduls zu erwähnen): CommonModuleMethod();

Sie sollten die „Global“-Eigenschaft allgemeiner Module nicht überall verwenden, weil Solche Module werden beim Systemstart kompiliert und verlangsamen den Start des Programms

Objektmodul

Viele Konfigurationsobjekte (Verzeichnisse, Dokumente usw.) verfügen über ein Objektmodul. Sie können darin Standardereignisse eingeben, z. B. das Erstellen eines neuen Verzeichniseintrags, das Erfassen eines neuen Objekts, das Löschen, das Verarbeiten einer Belegbuchung usw. Das Aufnahmeereignis existiert sowohl im Formularmodul (tritt während des interaktiven Aufnahmevorgangs auf, wenn der Benutzer auf die Schaltfläche „Aufzeichnen“ klickt) als auch im Objektmodul.

Es muss beachtet werden, dass ein Objekt mehrere Formen haben kann. Daher muss das Aufnahmeereignis im Objektmodul verarbeitet werden. Hier wird die Richtigkeit der erfassten Daten überprüft.

Ein Objektmodul kann über die Eigenschaftenpalette eines bestimmten Objekts oder über das Kontextmenü aufgerufen werden. Die Struktur eines Objektmoduls unterscheidet sich nicht von der eines Formularmoduls. Das Objektmodul wird auf dem Server kompiliert, daher sind keine Kompilierungsanweisungen erforderlich.

Formularmodul

Das Formularmodul dient zur Verarbeitung von Benutzeraktionen (Verarbeitung eines Schaltflächenklickereignisses usw.). Es gibt auch Ereignisse, die direkt mit dem Formular selbst verbunden sind (z. B. das Ereignis seines Öffnens, Schließens). Verwaltete und reguläre Formularmodule unterscheiden sich hauptsächlich dadurch, dass das verwaltete Formularmodul klar nach Kontext getrennt ist. Jede Prozedur muss eine Kompilierungsanweisung haben. In der Normalform wird der gesamte Code auf dem Client ausgeführt.

Die Struktur eines verwalteten Formulars enthält einen Abschnitt zur Beschreibung von Variablen, einen Abschnitt für Prozeduren und Funktionen und einen Abschnitt für das Hauptprogramm (das zum Zeitpunkt der Initialisierung des Formulars ausgeführt wird). Wir können über die Liste der Prozeduren und Funktionen (Strg+Alt+P) oder in der Eigenschaftenpalette des Formulars selbst auf Standardformularereignisse zugreifen. Sie können das Elementaufzeichnungsereignis auch in verwalteter Form verarbeiten (dieses Ereignis ist nur für Objekte vorhanden: Verzeichnisse, Dokumente).

Objektmanagermodul

Das Manager-Modul erschien nur in 1C 8.2; es ist in vielen Konfigurationsobjekten vorhanden. Der Hauptzweck des Objektmanagermoduls besteht darin, das Standardereignis „Verarbeitung des Empfangs von Auswahldaten“ zu überschreiben, und darin können wir auch

Modul „Value Manager“.

Das konstante Konfigurationsobjekt verfügt über kein Objektmodul, es gibt jedoch ein sehr ähnliches Modul – das Wertmanagermodul. Im Konstantwert-Manager-Modul können Sie verschiedene Verfahren (einschließlich Exportverfahren) beschreiben und 3 Ereignisse verarbeiten: BeforeWrite, OnWrite, ProcessingFillCheck. Dieses Modul wird auf dem Server kompiliert.

Recordset-Module

Das Recordset-Modul ist analog zum Objektmodul und ist in Registern verankert. Es gibt Standardereignisse im Recordset-Modul:

• Vor der Aufnahme
• Bei der Aufnahme
• Verarbeitung der Polsterkontrolle

Im Recordset-Modul gibt es einen Abschnitt für Beschreibungen von Variablen, Prozeduren und Funktionen (einschließlich Exportfunktionen) sowie einen Abschnitt für das Hauptprogramm.

1.1. Gemeinsame Module werden erstellt, um Verfahren und Funktionen zu implementieren, die nach bestimmten Merkmalen zusammengefasst sind. In der Regel werden Prozeduren und Funktionen eines Konfigurationssubsystems (Verkauf, Einkauf) oder Prozeduren und Funktionen ähnlicher Funktionalität (Arbeiten mit Strings, allgemeiner Zweck) in einem gemeinsamen Modul untergebracht.

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

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.

Gemeinsame Module sind für die Speicherung von Prozeduren und Funktionen verantwortlich, die von anderen Stellen im 1C-System aufgerufen werden. Es gilt als bewährte Vorgehensweise, Code, der in einer Prozedur mehrmals aufgerufen wird, in einem gemeinsamen Modul zu platzieren. Diese Regel gilt für alle Konfigurationen, daher sollte jeder 1C-Entwickler in der Lage sein, mit diesen Konfigurationsobjekten zu arbeiten. Dazu müssen Sie alle Nuancen verstehen und die Möglichkeiten der Plattform richtig nutzen können.

Erstellen eines gemeinsamen Moduls in 1C

Nach der Erstellung einer Funktion in einem der Objektmodule bestand die Notwendigkeit, einen ähnlichen Algorithmus an einer anderen Stelle zu verwenden. Hier ist es am besten, den Code in ein gemeinsames Modul zu übertragen, vorher müssen Sie ihn jedoch erstellen. Dazu müssen wir zum Konfigurator gehen und im Konfigurationsbaum die Registerkarte „Allgemein“ finden. Wählen Sie dann „Allgemeine Module“ aus und nutzen Sie den Button in Form eines weißen Pluszeichens auf dem grünen Kreis.

Die Eigenschaften des hinzugefügten gemeinsamen Moduls werden auf der rechten Seite geöffnet, und wir müssen herausfinden, was sie jeweils bedeuten. Sie können unterschiedliche Richtungen haben, daher ist es ratsam, vor dem Aufstellen eines neuen Objekts zu entscheiden, was wir dort aufbewahren möchten. Wenn überhaupt, wird es in Zukunft möglich sein, die Eigenschaften entsprechend den Aufgaben zu ändern:

• „Global“. Dieses Flag wird gesetzt, wenn das Modul Prozeduren und Funktionen speichern soll, die ohne Angabe des Modulnamens aufgerufen werden müssen. Selbstverständlich müssen sie exportierbar sein und ihre Namen müssen im Kontext des gesamten globalen Kontexts eindeutig sein. Sie werden sich in der Nutzung nicht von Standardplattformfunktionen unterscheiden;
• "Klient". Hängt von den Systemeinstellungen ab und regelt, ob Modulprozeduren clientseitig ausgeführt werden können;
• "Server". Es sind allgemeine Module gekennzeichnet, innerhalb derer Algorithmen zur Ausführung auf dem Server platziert werden sollen;
• „Äußerer Join“. Modulprozeduren mit aktivierter Eigenschaft können über die Verbindung einer externen Quelle ausgeführt werden;
• „Serveraufruf“. Verantwortlich dafür, dass Prozeduren vom Modul den Server aufrufen dürfen, während sie auf dem Client ausgeführt werden;
• "Privilegiert". Wenn Sie diese Einstellung aktivieren, können Sie die Zugriffsrechte beim Ausführen des Modulprozedurcodes nicht überprüfen. Mit dieser Einstellung können Sie ein gemeinsames Modul nur auf dem Server aufrufen. Die Einstellungen für Client und externe Verbindung werden zurückgesetzt;
• "Wiederverwendung". Kann folgende Werte annehmen: „Nicht verwenden“, „Für die Dauer der Sitzung“, „Für die Dauer des Anrufs“. Beim mehrmaligen Aufrufen einer Prozedur kann das System zuvor berechnete Daten innerhalb der Prozedur (Aufruf) oder die Lebensdauer der gesamten Sitzung (1C-Start) verwenden. Bei dieser Einstellung sollten Sie sehr vorsichtig sein, da es durch falsche Verwendung solcher Module zu Fehlern kommen kann.

Es gibt Situationen, in denen Sie ein gemeinsames Modul mit Prozeduraufrufen auf dem Server und Client mit unterschiedlichen Algorithmen erstellen müssen. Präprozessordirektiven mit Prüfung werden zum Begrenzen von Code verwendet. Infolgedessen handelt es sich um einen Code für den Serveraufruf und einen anderen für den Clientaufruf.
Procedure AlgorithmServerClient() Export #If ThinClient Then // der Code wird ausgeführt, wenn der Prozeduraufruf vom Client kam ShowUserAlert("On the client"); ElseIf Server Then // der Code wird ausgeführt, wenn der Prozeduraufruf vom Server kam VariableServer = "Server call"; #TheEndIfTheEndProcedure

Ein Beispiel für die Übertragung von Code an ein gängiges 1C-Modul

Betrachten wir eine Situation, in der wir zwei Ereignisse auf dem Dokumentformular haben, die ein Verfahren zur Multiplikation von Menge und Preis im tabellarischen Abschnitt beinhalten. Dies ist ein recht verbreiteter Algorithmus, wie er in vielen Beschaffungs- und Verkaufsdokumenten zu finden ist. Übertragen wir den Prozedurcode in ein gemeinsames Modul, das zunächst erstellt werden muss, um diesen Code in anderen Dokumenten verwenden zu können.

Da wir für unsere Aufgabe nur einen Anruf vom Client benötigen und keine Daten aus der Datenbank benötigen, setzen wir lediglich das Flag „Client“. Wenn Sie dasselbe Modul in Zukunft für komplexere Berechnungen verwenden möchten, dann aktivieren Sie „Server“ in den Eigenschaften. Die Vorbereitungsphase ist abgeschlossen und wir können mit dem Schreiben des Codes fortfahren.

Erstellen wir im Modul ein Exportverfahren und übertragen dort den Algorithmus zur Berechnung des Betrags aus dem Verfahren im Formularmodul. Der Tabellenabschnittsstring wird als Prozedurparameter am Eingang verwendet. Im Dokumentformularmodul ändern wir die Prozeduraufrufe im selben Modul in einen Prozeduraufruf aus dem allgemeinen Modul.

Fragment 1

Fragment 2

Beim Systemstart werden wir den Unterschied nicht bemerken, aber diese Codestruktur ist viel bequemer zu lesen und zu pflegen. Natürlich kann in diesem Beispiel die Menge an Code nicht alle Vorteile aufzeigen. Bei einem komplexen Algorithmus für Dutzende von Konfigurationsobjekten wirkt sich der Zuwachs an Codemenge und seiner Struktur auch auf die Geschwindigkeit des Systems aus. Darüber hinaus empfehlen erfahrene 1C-Entwickler, Algorithmen nicht in Formularmodulen zu beschreiben, sondern in richtig konfigurierten allgemeinen Modulen unterzubringen.

Bei der Entwicklung allgemeiner Module sollten Sie die allgemein anerkannten Regeln für deren Erstellung berücksichtigen:

• Platzieren Sie Prozeduren und Funktionen, die sich auf ähnliche Funktionen beziehen, in einem separaten gemeinsamen Modul.
• Der Name des Moduls sollte seine Zugehörigkeit zum Kontext (Client, Server) widerspiegeln und gebräuchliche Wörter (Handler, Prozeduren usw.) vermeiden;
• Trennen Sie die interne Serverlogik der Anwendung und die Clientlogik für die Schnittstelle.
• Seien Sie vorsichtig, wenn Sie ein globales gemeinsam genutztes Modul erstellen. Wenn der Modulname nicht auf eine Prozedur verweisen muss, kann dies zu Verwirrung führen, insbesondere wenn das System von mehreren Entwicklungsteams unterstützt wird.

Korrekt erstellte Module helfen Ihnen, sich in der Konfigurationsstruktur zurechtzufinden und Verbesserungen viel schneller vorzunehmen. Wenn Sie eine Möglichkeit sehen, eine nützliche Funktion universell zu machen und in einem gemeinsamen Modul unterzubringen, dann tun Sie es. Für diese Entscheidung werden Sie und Ihre Kollegen in Zukunft dankbar sein.