1초 안에 고객과 작업하기 위한 모듈입니다. 공통 모듈. 외부 조인 플래그

이 기사는 "1C 개발의 첫 번째 단계"시리즈를 계속하며 다음 문제에 대해 자세히 설명합니다.

소프트웨어 모듈이란 무엇이며 어떤 섹션으로 구성되어 있나요?
애플리케이션 모듈은 무엇입니까? 왜 두 개가 있습니까? 언제 출시되나요? 작품의 미묘함은 무엇입니까?
시스템 작동 시작과 관련된 이벤트는 무엇이며 이를 처리하는 방법과 위치는 무엇입니까?
외부 연결 모듈은 무엇입니까? 언제, 어떻게 사용하나요?
세션 모듈은 언제 사용되나요?
공통 모듈이란 무엇입니까? 그 속성과 운영 규칙은 무엇입니까? "반환 값 재사용" 속성을 사용하는 이유는 무엇입니까?
양식 모듈은 언제 사용되며 어떤 이벤트가 처리될 수 있나요?
객체 모듈은 무엇을 위한 것인가요? 어떤 섹션으로 구성되어 있나요? 사용 가능한 모듈 이벤트를 어떻게 확인할 수 있나요?
값 관리자 모듈(상수용) 및 레코드세트 모듈(레지스터용) 작업의 미묘한 점은 무엇입니까?
객체 모듈과 관리자 모듈의 차이점은 무엇입니까? 언제 후자를 사용해야 합니까?

적용 가능성

이 기사에서는 1C:Enterprise 플랫폼 8.3.4.496에 대해 설명합니다. 이 자료는 현재 플랫폼 릴리스와도 관련이 있습니다.

"1C:Enterprise 8.3"의 모듈

모듈은 프로그램 코드를 포함하는 개체입니다.

플랫폼에는 상당히 많은 유형의 모듈이 있으며 각 모듈에는 고유한 목적과 기능이 있습니다.

모든 코드 줄은 일부 모듈에 있어야 합니다. 범용 모듈과 객체 모듈이 있습니다. 일부 모듈은 클라이언트와 서버 모두에서 컴파일할 수 있고 일부 모듈은 서버에서만 컴파일할 수 있습니다.

모듈은 여러 섹션으로 구성될 수 있습니다. 변수 설명 섹션에서는 이후 모든 프로시저에서 사용할 수 있는 이 모듈의 지역 변수를 설명합니다.

각 프로시저 내에서 모듈 변수에 액세스할 수 있습니다. 또한 프로시저 자체 내에 동일한 이름을 가진 다른 변수 선언이 있을 수 있습니다. 이는 이 프로시저의 지역 변수가 됩니다.

동일한 이름에도 불구하고 이들은 두 가지 다른 변수입니다. 하나는 특정 프로시저 내부에서 사용되고 다른 하나는 외부에서 사용됩니다.

일부 모듈에서는 변수가 서버나 클라이언트의 컴파일 위치(가용성)를 나타낼 수 있습니다. 예를 들어:

변수를 설명하는 섹션 다음에는 이 모듈의 로컬 메서드가 표시되는 프로시저 및 함수 섹션이 옵니다. 일부 모듈은 프로시저나 함수가 컴파일될 위치를 지정해야 합니다.

원칙적으로 컴파일 지시문은 생략 가능합니다. 이 경우 기본 컴파일 지시문은 Server입니다. 그러나 프로그램 코드 분석의 편의를 위해 특정 프로시저가 컴파일될 위치를 명시적으로 나타내는 것이 좋습니다. 절차를 설명하는 순서는 중요하지 않습니다.

모듈 마지막에는 모든 절차와 기능을 설명한 후 일부 연산자를 포함하고 양식 모듈의 지역 변수를 초기화할 수 있는 기본 프로그램 섹션이 있습니다. 이 섹션은 모듈에 접근할 때 실행됩니다.

따라서 예를 들어 요소 양식을 열면 양식 모듈의 기본 프로그램 섹션이 먼저 실행됩니다.

변수 선언 섹션과 기본 프로그램 섹션은 모든 모듈에 존재하지 않는다는 점에 유의해야 합니다(즉, 이러한 섹션은 일부 모듈에서 유효하지 않습니다). 절차와 기능을 설명하는 섹션은 모든 모듈에 존재할 수 있습니다.

애플리케이션 모듈

이 모듈은 애플리케이션 시작 및 종료 이벤트를 처리하도록 설계되었습니다. 예를 들어, 애플리케이션을 실행하면 인터넷에서 환율을 다운로드할 수 있습니다. 애플리케이션을 종료할 때 종료 의사를 사용자에게 확인할 수 있습니다.

또한 애플리케이션 모듈에는 장비의 외부 이벤트를 가로챌 수 있는 특수 핸들러가 있습니다.

이는 자기 카드 판독기 또는 회계 등록 기관의 이벤트일 수 있습니다. 그리고 이러한 이벤트는 어떤 방식으로든 처리될 수 있습니다.

애플리케이션 모듈은 시스템의 대화형 실행을 모니터링합니다.

예를 들어 com 연결 모드에서 1C 프로그램이 실행되면 애플리케이션 모듈이 작동하지 않습니다. 이 경우 프로그램 창이 생성되지 않습니다.

Platform 8.3에는 관리형 애플리케이션 모듈과 일반 애플리케이션 모듈이라는 두 가지 애플리케이션 모듈이 있다는 점에 유의해야 합니다. 관리되는 애플리케이션 모듈 이벤트는 관리되는 애플리케이션 씬 및 씩 클라이언트와 웹 클라이언트가 시작될 때 처리됩니다.

기준 치수 정기신청모드에서 Thick 클라이언트를 실행할 때 작동 정기신청, 다음 형식의 일반적인 명령 인터페이스가 포함되어 있습니다. 메인 메뉴.

응용 프로그램이 실행 중인 경우 관리됨, 그리고 모드에서 정기신청, 모듈과 마찬가지로 핸들러 절차를 설명해야 합니다. 관리형 애플리케이션, 그리고 모듈의 경우 정기신청.

기준 치수 관리형 애플리케이션루트 구성 노드의 상황에 맞는 메뉴에서 선택할 수 있습니다.

이 모듈은 루트 구성 요소의 속성 팔레트에서도 열 수 있습니다.

모듈을 열려면 정기신청, 구성 설정(명령어)을 참조해야 합니다. 옵션메뉴에 서비스).

양식이 열립니다 옵션. 북마크에 흔하다구성 편집 모드를 지정해야 합니다. 관리형 애플리케이션그리고 정기신청.

이 경우 모듈 정기신청루트 노드의 속성에서도 열 수 있습니다.

처리할 수 있는 이벤트 목록 관리됨그리고 정기신청는 ~와 마찬가지로.

이 모듈에는 변수 선언 섹션, 임의 프로시저 및 함수에 대한 설명 섹션, 기본 프로그램 섹션이 포함될 수 있습니다. 그러나 임의의 프로시저 및 함수 외에도 특수 이벤트 핸들러가 모듈에 위치할 수 있습니다.

사용 가능한 핸들러 목록은 모듈이 열려 있을 때 현재 모듈의 프로시저 및 함수 목록을 호출하여 볼 수 있습니다.

열리는 프로시저 및 기능 창에는 이 모듈의 모든 프로시저와 기능은 물론 핸들러가 아직 생성되지 않은 이벤트도 표시됩니다.

시스템 시작과 관련된 두 가지 이벤트("이전" 및 "at")가 있습니다. 시스템 종료와 관련된 두 가지 이벤트("이전" 및 "시점"). 또한 외부 이벤트(예: 상업용 장비 이벤트) 처리도 가능합니다.

이전 이벤트 핸들러가 실행되면 해당 작업이 아직 발생하지 않은 것으로 간주됩니다. "at" 이벤트 핸들러가 실행되면 해당 작업이 이미 완료된 것입니다.

이벤트 시스템을 시작하기 전에 Enterprise 8.3이 실행되는 순간에 발생하지만 응용 프로그램 자체가 아직 화면에 나타나지 않습니다. 이 이벤트에는 다음 매개변수가 있습니다. 거절.

이 매개변수가 다음 값을 취하는 경우 진실, 그러면 응용 프로그램이 시작되지 않습니다. 이벤트 시스템을 시작할 때작업이 이미 완료되었고 창이 이미 생성되었다고 가정합니다. 이 경우 예를 들어 특별한 형식을 표시할 수 있습니다. 더 이상 발사를 거부할 수 없게 되었습니다.

마찬가지로, 시스템을 종료하기 전에 애플리케이션은 여전히 열려 있으므로 종료를 거부할 수 있습니다. 시스템이 종료되면 애플리케이션 창이 이미 닫힌 것입니다. 일부 파일을 삭제하거나 이메일을 보내는 등의 추가 작업만 수행할 수 있습니다.

모듈에서는 관리형 애플리케이션모듈이 클라이언트 측에서 완전히 컴파일되므로 프로시저 및 함수 컴파일에 대한 지시문은 지정되지 않습니다. 이는 모듈의 절차와 기능에서 참고 도서 등을 직접 액세스할 수 없음을 의미합니다.

모듈에서 온 경우 관리형 애플리케이션서버 호출을 해야 합니다. 이를 위해서는 특수한 호출을 생성해야 합니다. 깃발과 함께 .

모듈에서는 정기신청 Thick Client를 로드할 때 이 모듈이 컴파일되므로 그러한 제한은 없습니다. Thick Client에서는 거의 모든 유형의 데이터를 사용할 수 있습니다.

애플리케이션 모듈의 프로시저, 함수 및 변수는 내보내기로 설명될 수 있습니다.

모듈은 클라이언트에서 완전히 컴파일되므로 이는 클라이언트 프로시저에서 이 메서드와 이 속성에 액세스할 수 있음을 의미합니다.

예를 들어 개체의 양식 모듈에서 응용 프로그램 모듈의 프로시저나 함수를 호출할 수 있습니다. 그러나 일반적인 알고리즘을 설명하려면 공통 모듈을 사용하는 것이 좋습니다. 애플리케이션 모듈의 주요 목적은 시작점과 끝점을 처리하는 것입니다.

애플리케이션 모듈과 유사하게 이 모듈은 프로그램 열기 이벤트와 종료 이벤트를 처리하도록 설계되었습니다.

애플리케이션을 대화형으로 실행하는 순간 시작되는 애플리케이션 모듈과 달리 외부 연결 모듈은 COM 연결 모드에서 작동합니다. 1C:Enterprise 8 개체가 생성되어 특정 데이터베이스에 연결될 때.

이 모듈에는 다음과 같은 이벤트가 있습니다. 시스템을 시작할 때그리고 시스템 종료 시.

외부 연결 모듈은 루트 구성 개체 수준의 상황에 맞는 메뉴나 루트 노드의 속성 팔레트를 사용하여 열 수 있습니다.

외부 연결 프로세스 자체는 대화형이 아닌 정보 기반을 사용한 프로그래밍 작업 프로세스입니다. 따라서 현재로서는 사용자 인터페이스가 없기 때문에 대화 상자 양식을 사용하거나 경고 메시지를 표시할 수 없습니다.

외부 연결 모듈에서는 1C:Enterprise 8.3에 대한 외부 호출이 발생하는 측에서 사용할 수 있는 내보내기 변수 및 내보내기 방법을 설명할 수 있습니다.

외부 조인에는 사용자 인터페이스가 없으므로 외부 조인 모듈은 서버에서 완전히 컴파일됩니다.

세션 모듈

이 모듈은 세션 매개변수를 초기화하는 데 필요합니다. 세션 매개변수는 구성의 어느 곳에서나 값을 사용할 수 있는 빠른 전역 변수입니다.

상황에 맞는 메뉴나 루트 노드의 속성 팔레트를 통해 세션 모듈을 열 수 있습니다.

세션 모듈은 이벤트를 제공합니다. 설정세션 매개변수.

애플리케이션이 시작되면 이 프로시저가 먼저 호출됩니다. 모든 애플리케이션 작업에는 대화형으로 실행될 때와 외부 연결 모드에서 실행될 때 모두 세션 매개변수가 필요합니다.

세션 모듈은 다양한 조건에 따라 세션 매개변수를 초기화하는 다양한 작업을 설명합니다.

이 모듈은 일반적으로 프로시저에서 호출되는 여러 프로시저를 설명합니다. 설정세션 매개변수. 따라서 이러한 모든 절차는 별도의 모듈로 분리됩니다.

세션 모듈은 항상 특권 모드에서 실행됩니다. 이는 데이터베이스에 액세스할 때 권한 확인이 수행되지 않음을 의미합니다. 세션 모듈은 서버에서 컴파일됩니다. 모든 서버 메서드에 액세스할 수 있습니다(데이터베이스에서 값 읽기 포함).

세션 모듈에서는 절차와 기능만 정의하는 것이 가능합니다. 변수 설명 섹션과 기본 프로그램 섹션이 없습니다. 세션 모듈에서는 내보내기 방법을 정의할 수 없습니다.

시스템을 시작할 때 서버에서 일부 작업(예: 디렉토리 요소 생성)을 수행해야 하는 경우 옵션으로 세션 모듈을 사용할 수 있습니다. 이는 서버에서 컴파일되며 시스템 시작 시 항상 안정적으로 실행됩니다. 그러나 다음 사항을 고려해야 합니다.

절차 설정세션 매개변수시스템 시작 시뿐만 아니라 초기화되지 않은 세션 매개변수에 액세스할 때도 실행됩니다. 저것들. SetSessionParameters 핸들러는 애플리케이션 작업 중에 반복적으로 호출될 수 있습니다.
세션 매개변수 배열의 요소 수가 0이면(필수 매개변수 배열의 데이터 유형이 정의되지 않음) 애플리케이션이 시작되는 순간입니다.
세션 모듈은 특권 모드에서 작동하고 액세스 권한을 확인하지 않으므로 사용자가 자신에게 제공되어서는 안 되는 데이터에 액세스할 수 있으므로 데이터베이스 개체에 대해 매우 주의 깊게 작업해야 합니다.
시스템이 시작되면 애플리케이션이 실행될지는 아직 확실하지 않습니다. 이 경우 SetSessionParameters 이벤트 핸들러에서 불필요한 작업이 수행될 수 있습니다.

이 모듈은 몇 가지 일반적인 알고리즘에 대한 설명을 나타냅니다. 다양한 곳에서 호출할 수 있는 프로시저와 함수.

논리적으로 관련된 메소드는 서로 다른 공통 모듈로 그룹화될 수 있습니다. 이러한 모듈은 일반 분기 내부에 생성됩니다.

공통 모듈을 원하는 만큼 추가할 수 있습니다. 구성의 다른 곳에서 공통 모듈 메서드를 사용할 수 있게 하려면 해당 메서드를 내보내기 키워드로 정의해야 합니다. 공통 모듈의 클라이언트 프로시저는 클라이언트에서, 서버 프로시저는 서버에서 사용할 수 있습니다.

일반 모듈에서는 절차와 기능을 설명하는 섹션만 사용할 수 있습니다. 저것들. 일반 모듈에서는 변수를 설명할 수 없으며 기본 프로그램의 섹션을 설명할 수 없습니다.

전역 변수가 필요한 경우 세션 매개변수 또는 애플리케이션 모듈 내보내기 변수를 사용할 수 있습니다.

일반 모듈의 경우 이 모듈의 동작에 영향을 미치는 일부 매개변수를 설정할 수 있습니다. 일반 모듈에 대해 전역 속성이 설정된 경우 이 모듈에서 선언된 내보내기 메서드는 추가 지침 없이 외부에서 직접 액세스할 수 있습니다.

저것들. 그만큼 일반 모듈전역 구성 컨텍스트의 형성에 참여합니다.

재산 글로벌일반 모듈의 경우 유용할 수 있습니다. 그러나 모든 공통 모듈에 대해 모든 곳에서 이를 사용해서는 안 됩니다.

저것들 , 기호로 표시되어 있습니다. 글로벌, 시스템 시작 시 컴파일됩니다. 이러한 모듈이 많을수록 프로그램 시작 속도가 느려집니다.

깃발이라면 글로벌을 위한 일반 모듈지정되지 않은 경우 이 모듈의 컴파일은 해당 모듈을 처음 호출할 때(즉, 시스템이 시작된 후) 수행됩니다.

또한, 전역 공통 모듈의 사용은 코드의 이해에 영향을 미칩니다. 비전역 공통 모듈의 메소드는 이름을 통해 호출됩니다. 일반 모듈메소드 이름은 다음과 같습니다.
비용 계산 Module.DistributeIndirectCosts();

이 경우 공통 모듈의 이름은 해당 모듈에 설명된 절차의 내용을 반영해야 합니다. 프로시저를 호출할 때 공통 모듈의 이름을 지정하면 코드를 더 잘 이해하는 데 도움이 됩니다.

을 위한 일반 모듈 V 특성 팔레트속성을 설정할 수 있습니다 특권.

권한 있는 모듈은 접근 권한을 제어하지 않습니다. 다음과 같은 경우에 필요합니다. 일반 모듈대량의 데이터 처리를 수행하고 데이터베이스에서 데이터를 얻어야 합니다.

액세스 권한을 제어하면 데이터베이스에 액세스하는 데 걸리는 시간이 늘어나고 대량 알고리즘은 가능한 한 빨리 작동해야 하는 경우가 많습니다.

예를 들어 급여는 자원 집약적인 작업입니다. 가능한 한 빨리 완료해야합니다. 이를 달성하기 위해 임금을 계산하는 알고리즘은 특권층에 배치됩니다. .

동시에 급여 문서 작성을 보장하는 모든 절차는 이 범위를 벗어납니다. 공통 모듈. 이러한 절차에서 액세스 권한 제어가 수행됩니다.

이러한 방식으로 상당한 성능 향상을 달성할 수 있습니다. 이는 테이블 레코드에 대한 행별 액세스 제어 메커니즘을 사용할 때 특히 그렇습니다.

공통 모듈에 권한이 있으면 이 모듈의 절차는 서버에서만 컴파일될 수 있습니다.

사용자가 일부 개체(예: 특정 디렉터리)에 액세스할 수 없는 상황이 있습니다. 그러나 하나의 문서를 작성할 때에는 이 참고서를 참조하는 것이 필요합니다.

저것들. 일시적으로 사용자 권한을 확장한 후 원래 상태로 되돌려야 할 필요가 있습니다. 이 효과는 특권을 사용하여 얻을 수 있습니다. 공통 모듈.

특권층에서 이를 수행하려면 일반 모듈필요한 데이터에 액세스하는 프로시저를 만들어야 합니다.

이 절차는 해당 문서에서 호출됩니다. 저것들. 이 프로시저가 호출될 때 사용자에게는 실제로 확장된 권한이 부여됩니다.

을 위한 공통 모듈컴파일 위치를 지정할 수 있습니다. 플래그는 공통 모듈을 클라이언트(관리 응용 프로그램), 서버 또는 외부 연결 모드에서 사용할 수 있는지 여부를 결정하는 데 사용됩니다.

또한 구성 편집 모드를 관리형 애플리케이션과 일반 애플리케이션으로 전환하면 클라이언트(일반 애플리케이션)라는 또 다른 컴파일 컨텍스트가 가능해집니다.

따라서 프로그램 기능에는 네 가지 옵션이 있습니다. 실행 중인 애플리케이션에 따라, 클라이언트나 서버에서의 작업에 따라 특정 공통 모듈을 사용하거나 사용할 수 없습니다.

컴파일 플래그를 지정하는 기능 외에도 공통 모듈에 있는 프로시저 및 함수에 대한 컴파일 지시문을 지정할 수 있습니다.

메서드에 대해 컴파일 지시문이 지정된 경우 지정된 모든 컨텍스트에서 공통 모듈을 사용할 수 있더라도 특정 메서드의 가용성은 컴파일 지시문에 의해 제한됩니다.

이 경우 전체 모듈에 액세스할 수 없는 컨텍스트에서는 프로시저에 액세스할 수 없습니다.

프로시저(함수)에 대한 컴파일 지시문을 지정하지 않으면 해당 모듈에 정의된 모든 컨텍스트에서 컴파일됩니다.

저것들. 기본적으로 절차의 여러 복사본이 만들어집니다. 특정 컴파일된 인스턴스의 선택은 프로시저가 호출되는 위치(가장 가까운 호출 규칙에 따라)에 따라 달라집니다. 그러한 프로시저의 코드는 모듈에 대해 정의된 모든 컨텍스트에서의 가용성을 고려하여 작성되어야 한다는 점을 고려해야 합니다.

여러 다른 컨텍스트에서 동시에 액세스할 수 있는 일반 모듈은 주로 여러 컨텍스트에서 액세스할 수 있는 프로시저를 생성하도록 설계되었습니다.

일반 모듈을 생성할 때 컴파일 지시문을 지정하지 않는 것이 좋습니다. 저것들. 프로시저와 기능의 가용성은 모듈 자체의 속성에 따라 결정되어야 합니다.

이 접근 방식을 사용하면 클라이언트 프로시저가 별도의 공통 모듈에 위치하고 서버 프로시저가 별도의 공통 모듈에 위치하게 됩니다.

여러 컴파일 플래그가 설정된 모듈은 실제로는 극히 드물게 사용됩니다. 다음은 클라이언트와 서버 모두에서 사용할 수 있는 몇 가지 일반적인 작업입니다. 일반적으로 이는 몇 가지 간단한 계산입니다.

중요한! 클라이언트가 공통 모듈의 내보내기 서버 메소드에 액세스하는 것이 가능하지만 이 공통 모듈이 서버에서만 컴파일된 경우에만 가능합니다. 이 경우 클라이언트의 액세스를 제공하기 위해 특수 플래그가 제공됩니다. .

비전역 공통 모듈의 경우 함수에서 반환된 값을 캐시할 수 있습니다. 저것들. 함수를 처음 호출한 후 시스템은 해당 함수의 실행 결과를 기억할 수 있습니다. 동일한 매개변수를 사용하여 이 함수를 다시 호출하면 시스템은 캐시에서 값을 반환합니다.

이 메커니즘의 목적은 반복 호출 속도를 높이는 것입니다. 이 동작을 구성하려면 다음을 수행해야 합니다. 특성 팔레트모듈에서 반환 값 재사용 속성에 적절한 값을 설정합니다.

기본적으로 이 속성은 사용하지 않음으로 설정됩니다. 기타 가능한 값: 캐시 통화 중, 또는 세션 기간 동안.

이 속성은 결과가 입력 매개변수에만 의존하는 함수에만 사용하는 것이 좋습니다. 이 메커니즘은 비전역 공통 모듈에만 사용할 수 있습니다.

호출 기간 동안 해당 매개 변수의 값을 선택한 경우 일반 모듈 메서드가 호출된 프로시저가 실행되는 동안 캐시가 작동합니다. 세션 기간 동안 값을 선택한 경우 사용자가 작업하는 동안 캐시가 작동한다고 조건부로 가정됩니다.

그러나 특정 시간 제한이 있습니다. 값이 캐시에 입력된 후 20분이 지나면 캐시가 자동으로 지워집니다.

양식 모듈

이 모듈은 사용자 작업을 처리하도록 설계되었습니다. 예를 들어, 버튼을 눌렀을 때 프로그램이 어떻게 반응하는지에 대한 알고리즘을 설명하세요. 또는 예를 들어 필드에 값을 입력하는 순간 즉시 정확성을 확인합니다.

양식 컨트롤(버튼, 입력 필드)과 관련된 이벤트 외에도 양식 자체와 직접 관련된 이벤트가 있습니다.

예를 들어, 양식의 열기 이벤트를 처리하고 일부 초기 초기화를 수행할 수 있습니다. 또한 양식 닫기 이벤트를 처리하고 사용자가 모든 항목을 올바르게 입력했는지 확인할 수도 있습니다.

제어형과 일반형이 있습니다. 이러한 양식의 모듈은 주로 관리 양식 모듈이 컨텍스트로 명확하게 구분된다는 점에서 다릅니다. 각 프로시저(함수)에는 컴파일 지시문이 있어야 합니다. 일반적인 형태에서는 모든 코드가 클라이언트에서 사용됩니다.

관리되는 양식 모듈에서는 프로시저와 함수를 선언하고, 변수를 선언하고, 기본 프로그램의 섹션을 설명할 수 있습니다.

기본 프로그램의 프로그램 코드는 양식 초기화 시 실행됩니다. 사용자가 그것을 열기 시작하면. 그림은 관리되는 양식에 대한 표준 이벤트 목록을 보여줍니다.

관리되는 양식의 이벤트 목록은 양식 자체에 대한 속성 목록에서도 직접 볼 수 있습니다. 이 목록은 관리되는 양식 편집기에서 호출됩니다.

관리되는 양식에서는 항목의 쓰기 이벤트를 처리할 수 있습니다. 이 이벤트는 개체 양식(디렉터리, 문서 및 기타 일부)에 대해서만 존재합니다. 양식이 특정 개체에 바인딩되지 않은 경우 쓰기 이벤트가 없습니다.

일반 형식 모듈의 경우 표준 이벤트 목록이 다소 작습니다. 관리되는 형태에서는 많은 이벤트가 쌍으로 만들어집니다(하나는 클라이언트에서 실행되고 다른 하나는 서버에서 실행됨). 일반적인 형태에서는 모든 코드가 클라이언트에서 실행됩니다.

개체 모듈

이러한 모듈은 디렉터리, 문서, 계산 유형 계획, 계정과목표 및 기타 여러 개체에 일반적으로 사용됩니다. 개체 모듈은 표준 이벤트를 처리하도록 설계되었습니다. 예를 들어 디렉토리 요소 입력 이벤트, 요소 쓰기, 삭제, 문서 게시 이벤트 등이 있습니다.

원칙적으로 쓰기 이벤트는 Form 모듈에도 존재합니다. 그러나 양식 모듈의 쓰기 이벤트는 특정 양식으로 작업할 때 대화형 기록 프로세스 중에 발생합니다.

개체 모듈의 쓰기 이벤트는 지정된 개체의 모든 형식에서 쓰기 시 실행됩니다. 또한 개체가 프로그래밍 방식으로 작성된 경우 개체의 모듈 이벤트가 발생합니다.

개체 모듈의 쓰기 이벤트에서는 기록되는 데이터의 정확성에 대한 모든 검사를 작성할 수 있습니다. 왜냐하면 이 절차는 모든 기록 시 실행되기 때문입니다.

이 개체의 모듈은 컨텍스트 메뉴, 개체 속성 팔레트 및 개체 편집 창을 통해 호출할 수 있습니다.

아래 그림은 사용 가능한 디렉터리 모듈 이벤트 목록을 보여줍니다.

개체 모듈에는 변수를 설명하는 섹션, 이벤트와 연관되지 않을 수 있는 임의의 기능을 설명하는 섹션 및 기본 프로그램 섹션을 배치할 수 있습니다.

예를 들어 기본 프로그램 섹션에서는 특정 모듈의 지역 변수를 초기화할 수 있습니다. 이 프로그램 코드는 이 개체 모듈에 액세스할 때 실행됩니다.

개체 모듈의 모든 절차는 서버에서 컴파일된다는 점에 유의해야 합니다. 따라서 개체 모듈의 프로시저 및 기능에 대한 컴파일 지시문이 필요하지 않습니다. 일부 구성 개체에는 개체 모듈이 없습니다.

이는 개체 자체의 특성 때문입니다. 이러한 개체에는 다음이 포함됩니다. 상수그리고 레지스터. 을 위한 끊임없는개체 모듈은 없지만 다음과 같은 매우 유사한 모듈이 있습니다. 가치 관리자 모듈.

안에 가치 관리자 모듈쓰기 이벤트를 처리할 수 있습니다 상수및 채우기 검증 처리.

모듈의 전체 컨텍스트는 서버에서 실행됩니다.

레지스터에는 레코드세트 모듈이 있습니다.

이 모듈에는 쓰기 이벤트를 처리하고 점유 확인을 수행하는 기능도 있습니다.

개체 모듈, 값 관리자 모듈(상수용) 및 레코드 집합 모듈(레지스터용)에서 내보낼 수 있는 메서드를 설명할 수 있으며 이러한 메서드는 외부에서 액세스할 수 있습니다.

저것들. 개체 클래스의 고정 메서드를 사용하는 것 외에도 개체 모듈에서 개체에 대한 추가 메서드를 만들 수 있습니다. 이 모듈은 키워드를 사용하여 해당 절차를 설명해야 합니다. 내보내다.

그러면 외부에서 이 절차에 액세스할 수 있게 됩니다. 또한 이 메서드는 컨텍스트 도구 설명에 표시됩니다. 컨텍스트 도구 설명의 새 메서드는 파란색 글꼴(파란색 아이콘)로 강조 표시됩니다. 피()절차와 에프()기능의 경우).

마찬가지로 키워드를 사용하여 변수를 선언하여 새 속성을 만들 수 있습니다. 내보내다. 이 숙소는 외부에서도 접근이 가능합니다.

이런 방식으로 객체의 기능을 확장하는 것이 가능합니다(새로운 메소드와 새로운 속성을 정의하기 위해). 그러나 속성은 동적이며 데이터베이스에 저장되지 않습니다.

데이터베이스에 저장될 객체에 대한 속성을 사용해야 하는 경우 객체 속성을 생성해야 합니다.

관리자 모듈

이 모듈은 많은 개체(디렉터리, 문서, 레지스터 등)에 대해 존재합니다. 모듈은 개체의 상황에 맞는 메뉴를 통해 열리거나 다음을 통해 열립니다. 특성 팔레트, 또는 편집 창을 통해.

관리자 모듈에서는 다음과 같은 일부 표준 이벤트를 무시할 수 있습니다. 처리수신선택데이터, 디렉토리에서 요소를 선택하면 추가 필터링 또는 확인이 수행될 수 있습니다.

또한 관리자 모듈에서는 추가 방법을 생성하고 해당 방법이 내보내기 방법임을 표시할 수 있습니다. 이 경우 외부에서 해당 메소드에 접근하는 것이 가능합니다.

이 호출을 수행하려면 데이터 유형을 얻어야 합니다. 디렉토리 관리자.

관리자 모듈의 내보내기 방법과 개체 모듈의 차이점은 개체 모듈의 방법에 액세스하려면 먼저 개체 자체를 얻어야 한다는 것입니다(즉, 어떻게든 링크를 얻은 다음 이 링크를 개체로 변환합니다). .

그 후에는 개체 모듈의 내보내기 변수와 메서드를 사용할 수 있습니다. 관리자 모듈의 경우 호출이 더 간단합니다. 예를 들면 다음과 같습니다.
디렉터리.상대방.방법 이름

이는 두 가지 다른 호소입니다. 참조에서 객체로 변환(메서드 GetObject)은 객체를 수신할 때 이 객체의 모든 데이터를 읽어야 하기 때문에 시스템에 상당히 심각한 작업입니다. 이는 상당히 길 수 있습니다.

두 번째 차이점은 개체 모듈특정 요소의 컨텍스트에서 호출됩니다. 따라서 주어진 요소에 적용 가능하다고 가정할 수 있습니다(대부분의 경우 이것이 정확히 사용되는 논리입니다).

관리자 모듈의 경우 그룹이나 디렉토리 또는 일부 문서의 모든 요소에 대한 몇 가지 일반적인 작업을 설명합니다. 예를 들어 디렉터리 항목을 인쇄해야 하는 경우 개체 모듈을 사용할 수 있습니다.

그러나 관리자 모듈에서는 무엇보다도 요소 그룹을 인쇄하는 보다 보편적인 메커니즘을 만드는 것이 가능합니다.

또한 개체 모듈에 액세스하는 데는 여전히 시간이 더 걸립니다. 따라서 이 문제는 관리자 모듈에서 해결하는 것이 더 바람직합니다.

이것으로 1C:Enterprise 시스템 구성의 모듈에 대한 지식을 마칩니다. 위의 내용을 모두 간략하게 요약하면 결론은 다음과 같습니다.

소프트웨어 모듈은 내장된 1C 언어의 텍스트만 포함할 수 있는 구성의 일부입니다.
소프트웨어 모듈은 이 기사에서 논의한 유형에 따라 분류됩니다. 각 보기는 배치 및 사용 가능한 프로그램 컨텍스트에 따라 결정됩니다.
모듈의 구조는 특정 순서로 배열된 여러 섹션으로 구성됩니다. 섹션의 구성은 모듈 유형에 따라 결정됩니다.

또한 우리는 의도적으로 한 가지 유형의 모듈, 즉 명령 모듈을 생략했습니다. 이는 놀라운 것이 아니며, 그 기능을 숙지하시기 바랍니다.

지금까지 우리는 모든 프로그램 코드를 애플리케이션 솔루션과 별도로 고려했으며 원칙적으로 자체적인 소규모 테스트 구성으로 코드를 작성했습니다. "그냥 갈 수는 없다"고 표준 구성의 코드 편집을 시작할 수 없다는 것을 알고 계십니까? 아니요? 그러면 다음 기사에서 모두 설명하겠습니다!

1.1. 공통 모듈은 특정 특성에 따라 통합된 절차와 기능을 구현하기 위해 생성됩니다. 일반적으로 하나의 구성 하위 시스템(판매, 구매)의 프로시저 및 기능이나 유사한 기능(문자열 작업, 범용)의 프로시저 및 기능은 하나의 공통 모듈에 배치됩니다.

1.2. 공유 모듈을 개발할 때 다음 네 가지 코드 실행 컨텍스트 중 하나를 선택해야 합니다.

	공통 모듈 유형	이름의 예	서버 호출	섬기는 사람	외부 조인	고객 (정기 신청)	고객 (관리형 애플리케이션)
1.	섬기는 사람	범용(또는 범용 서버)
2.	클라이언트에서 호출할 서버	일반목적CallServer
3.	고객	범용 클라이언트(또는 범용 글로벌)
4.	클라이언트 서버	범용클라이언트서버

2.1. 서버 공통 모듈클라이언트 코드에서 사용할 수 없는 서버 프로시저 및 기능을 호스트하기 위한 것입니다. 이는 애플리케이션의 모든 내부 서버 비즈니스 로직을 구현합니다.
외부 연결, 관리 및 일반 응용 프로그램 모드에서 구성이 올바르게 작동하려면 서버 프로시저 및 기능이 다음 특성을 가진 공통 모듈에 배치되어야 합니다.

섬기는 사람(체크박스 서버 호출초기화),
클라이언트(정규신청),
외부 조인.

이 경우 변경 가능한 유형의 매개변수를 사용하여 서버 프로시저 및 함수를 호출하는 기능이 보장됩니다(예: 디렉토리객체, DocumentObject등등.). 일반적으로 이는 다음과 같습니다.

변경 가능한 값(객체)을 매개변수로 사용하는 문서, 디렉터리 등의 이벤트 구독을 위한 핸들러입니다.
디렉터리, 문서 등의 모듈과 이벤트 구독이 있는 모듈에서 객체가 매개변수로 전달되는 서버 프로시저 및 함수.

서버측 공유 모듈의 이름은 메타데이터 개체 이름 지정에 대한 일반 규칙에 따라 지정됩니다.
예를 들어: 파일 작업, 범용

경우에 따라 전역 컨텍스트 속성과 이름 충돌을 방지하기 위해 접미사를 추가할 수 있습니다. "섬기는 사람".
예를 들어: 루틴작업서버, 데이터 교환서버.

2.2. 클라이언트에서 호출하기 위한 서버 공통 모듈클라이언트 코드에서 사용할 수 있는 서버 프로시저와 함수를 포함합니다. 이는 애플리케이션 서버의 클라이언트 프로그래밍 인터페이스를 구성합니다.
이러한 절차와 기능은 다음 기능을 갖춘 공통 모듈에 배치됩니다.

섬기는 사람(체크박스 서버 호출설치됨)

클라이언트에서 호출하기 위한 서버측 공통 모듈은 메타데이터 개체 이름 지정에 대한 일반 규칙에 따라 이름이 지정되며 접미사를 사용하여 이름을 지정해야 합니다. "콜서버".
예를 들어: FilesCalling 서버 작업

이러한 공유 모듈의 내보내기 프로시저와 함수에는 변경 가능한 유형의 매개변수가 포함되어서는 안 됩니다( 디렉토리객체, DocumentObject등), 클라이언트 코드에서(또는 클라이언트 코드로) 전송이 불가능하기 때문입니다.

또한보십시오:공통 모듈에 대한 "서버 호출" 플래그 설정에 대한 제한

2.3. 클라이언트 공통 모듈클라이언트 비즈니스 로직(클라이언트에 대해서만 정의된 기능)을 포함하며 다음과 같은 특징을 갖습니다.

클라이언트(관리형 애플리케이션))
클라이언트(정규신청)

클라이언트 프로시저와 기능을 관리형 애플리케이션 모드(일반 애플리케이션 모드 또는 외부 연결 모드에서만)에서만 사용할 수 있어야 하는 경우는 예외입니다. 그러한 경우에는 이 두 가지 특성의 또 다른 조합이 허용됩니다.

클라이언트 공통 모듈의 이름은 접미사로 지정됩니다. "고객".
예를 들어: FilesClient 작업, 범용클라이언트

참고 항목: 클라이언트에서 실행되는 코드 최소화

2.4. 어떤 경우에는 서버와 클라이언트 모두에서 내용이 동일한 프로시저와 기능을 포함하는 클라이언트-서버 공통 모듈을 생성하는 것이 허용됩니다. 이러한 절차와 기능은 다음과 같은 특성을 지닌 공통 모듈에 배치됩니다.

클라이언트(관리형 애플리케이션)
섬기는 사람(체크박스 서버 호출초기화)
클라이언트(정규신청)
외부 조인

이 유형의 공통 모듈은 접미사로 이름이 지정됩니다. "클라이언트 서버".
예를 들어: FilesClient 작업, 범용클라이언트서버

일반적으로 서버와 클라이언트(관리 애플리케이션) 모두에 공통 모듈을 정의하는 것은 권장되지 않습니다. 클라이언트와 서버에 대해 정의된 기능을 서로 다른 공통 모듈로 구현하는 것이 좋습니다. 단락을 참조하세요. 2.1과 2.3. 클라이언트와 서버 비즈니스 로직의 이러한 명시적인 분리는 애플리케이션 솔루션의 모듈화 증가, 클라이언트-서버 상호 작용에 대한 개발자 제어 단순화, 클라이언트와 서버 개발 요구 사항의 근본적인 차이로 인한 오류 위험 감소 등을 고려하여 결정됩니다. 코드(클라이언트에서 실행되는 코드를 최소화해야 하는 필요성, 개체의 다양한 가용성 및 플랫폼 유형 등). 이 경우 구성에서 공통 모듈 수가 불가피하게 증가한다는 점을 염두에 두어야 합니다.

혼합 클라이언트-서버 모듈의 특별한 경우는 하나의 모듈에서 서버 및 클라이언트 비즈니스 로직을 구현하도록 특별히 설계된 양식 및 명령 모듈입니다.

3.1. 공통 모듈의 이름은 메타데이터 개체 이름 지정에 대한 일반 규칙을 따르는 것이 좋습니다. 일반 모듈의 이름은 하위 시스템이나 별도의 메커니즘, 해당 모듈이 구현하는 절차 및 기능의 이름과 일치해야 합니다. 공통 모듈 이름에는 "Procedures", "Functions", "Handlers", "Module", "Functionality" 등과 같은 일반적인 단어를 사용하지 않는 것이 좋습니다. 그리고 모듈의 목적을 더 완전하게 드러내는 예외적인 경우에만 사용하세요.

서로 다른 컨텍스트에서 수행되는 절차와 기능을 구현하기 위해 생성된 하나의 하위 시스템의 공통 모듈을 구별하려면 이전 단락에서 설명한 접미사를 제공하는 것이 좋습니다. 2.1-2.4.

모듈이란 무엇이며 정확히 무엇을 위한 것입니까? 모듈에는 프로그램 코드가 포함되어 있습니다. 또한 코드가 양식 요소의 속성과 레이아웃 테이블의 셀에 있을 수 있는 7.7 플랫폼과 달리 8.x 플랫폼에서는 모든 코드 줄이 일부 모듈에 있어야 한다는 점에 주목할 가치가 있습니다. . 일반적으로 모듈은 변수를 설명하는 섹션, 프로시저 및 기능을 설명하는 섹션, 기본 프로그램을 설명하는 섹션의 세 가지 섹션으로 구성됩니다. 이 구조는 일부 예외를 제외하고 거의 모든 플랫폼 모듈에 일반적입니다. 일부 모듈에는 변수 설명 섹션이나 기본 프로그램 섹션이 없습니다. 예를 들어 세션 모듈 및 일반 모듈이 있습니다.

모듈의 실행 컨텍스트는 일반적으로 클라이언트와 서버로 구분됩니다. 또한 일부 모듈은 클라이언트 측과 서버 측 모두에서 컴파일될 수 있습니다. 그리고 일부는 서버 측이나 클라이언트 측에만 독점적으로 존재합니다. 그래서:

애플리케이션 모듈

이 모듈은 애플리케이션 실행(구성 로딩) 및 작업 종료 순간을 포착하도록 설계되었습니다. 그리고 해당 이벤트에 검증 절차를 둘 수 있습니다. 예를 들어, 애플리케이션을 시작할 때 일부 참조 구성 데이터를 업데이트하고, 작업을 마칠 때 아예 종료할 가치가 있는지 물어보세요. 작업일이 아직 끝나지 않았을 수도 있습니다. 또한 거래나 재정과 같은 외부 장비의 이벤트를 가로챕니다. 애플리케이션 모듈은 대화형으로 실행될 때만 설명된 이벤트를 가로채는 점에 주목할 가치가 있습니다. 저것들. 프로그램 창 자체가 생성될 때. 응용프로그램이 com 연결 모드에서 실행되는 경우에는 이런 일이 발생하지 않습니다.

8.2 플랫폼에는 두 가지 서로 다른 애플리케이션 모듈이 있습니다. 이는 일반 애플리케이션 모듈과 관리형 애플리케이션 모듈입니다. 다른 클라이언트가 시작될 때 트리거됩니다. 이는 웹 클라이언트, 씬 클라이언트 및 씩 클라이언트가 관리형 애플리케이션 모드에서 실행될 때 관리형 애플리케이션 모듈이 트리거되는 방식입니다. 그리고 일반 애플리케이션 모드에서 씩 클라이언트가 시작되면 일반 애플리케이션 모듈이 트리거됩니다.

애플리케이션 모듈에는 변수, 프로시저, 함수에 대한 설명은 물론 기본 프로그램에 대한 설명 등 모든 섹션이 포함될 수 있습니다. 애플리케이션 모듈은 클라이언트 측에서 컴파일되므로 다양한 유형의 데이터 가용성이 크게 제한됩니다. "서버 호출" 속성이 설정된 공통 모듈의 메서드를 사용하여 애플리케이션 모듈 컨텍스트를 확장할 수 있습니다. 내보내기로 표시된 모든 변수와 메소드는 클라이언트 측에서 실행되는 모든 구성 모듈에서 사용할 수 있습니다. 그러나 유혹적일 수 있지만 여기에 많은 방법을 게시해서는 안됩니다. 포함된 코드가 많을수록 컴파일 시간이 길어지고 그에 따라 애플리케이션 실행 시간도 길어지며 이는 사용자에게 매우 짜증나는 일입니다.

위에서 언급한 것처럼 애플리케이션 모듈은 애플리케이션 시작 및 종료 이벤트를 처리합니다. 애플리케이션 모듈에서 이러한 각 이벤트를 처리하기 위해 Before... 및 When... 핸들러 쌍이 있습니다. 둘 사이의 차이점은 Before... 핸들러에서 코드를 실행할 때 작업이 아직 수행되지 않았다는 것입니다. 발생했으며 당사는 이를 거부할 수 있습니다. 이것이 거부 옵션의 목적입니다. On.. 핸들러에서는 작업이 이미 수행되었으며 애플리케이션 실행을 거부하거나 종료할 수 없습니다.

외부접속모듈

모듈의 목적은 애플리케이션 모듈의 목적과 유사합니다. 애플리케이션의 시작점과 끝점을 처리합니다. 외부 연결 모듈은 애플리케이션이 com 연결 모드에서 실행될 때 트리거됩니다. 외부 조인 프로세스 자체는 비대화형 프로세스입니다. 이 모드에서는 정보 기반을 사용한 프로그래밍 작업이 발생하고 응용 프로그램 창이 열리지 않으므로 대화형 작업을 위한 메서드 사용에 특정 제한이 적용됩니다. 이 모드에서는 대화창 호출, 경고 메시지 등을 사용할 수 없습니다. 그들은 단지 작동하지 않을 것입니다.

애플리케이션 모듈에서와 마찬가지로 변수, 메소드를 설명하는 섹션과 기본 프로그램에 대한 섹션을 여기에서 사용할 수 있습니다. 내보내기 변수와 메서드를 선언할 수도 있습니다. 차이점은 com 연결 모드에서는 정보베이스에 대한 모든 작업이 서버 측에서 발생하므로 외부 연결 모듈은 서버에서만 컴파일된다는 것입니다. 따라서 일반 클라이언트 모듈의 내보내기 변수 및 메소드를 사용할 수 없습니다.

세션 모듈

이는 고도로 전문화된 모듈이며 세션 매개변수 초기화에만 사용됩니다. 왜 이를 위해 자체 모듈을 만들어야 했나요? 이는 초기화 프로세스에 일부 코드 실행이 필요할 수 있고, 또한 애플리케이션이 다른 클라이언트에서 실행될 수 있기 때문입니다(이로 인해 다른 애플리케이션 모듈 또는 외부 연결 모듈이 실행됨). 세션 매개변수는 모든 시작 모드에서 수행되어야 합니다. 따라서 모든 애플리케이션 시작 모드에서 실행되는 추가 모듈이 필요했습니다.

세션 모듈에는 애플리케이션 모듈 이벤트 BeforeSystemStartOperation 이전에도 가장 먼저 실행되는 단일 이벤트 "SettingSessionParameters"가 있습니다. 변수 선언 섹션과 기본 프로그램 섹션을 사용할 수 없습니다. 내보내기 방법도 선언할 수 없습니다. 모듈은 서버 측에서 컴파일됩니다.

애플리케이션이 시작될 때마다 이 모듈이 실행된다는 사실에 현혹되어서는 안 되며, 세션 매개변수 초기화와 직접적으로 관련되지 않은 코드를 모듈에 배치해서는 안 됩니다. 이는 시스템 작동 중에 SetSessionParameters 핸들러가 반복적으로 호출될 수 있기 때문입니다. 예를 들어 초기화되지 않은 매개변수에 액세스하는 경우에 이런 일이 발생합니다. 이 이벤트가 처음 실행되는 순간을 포착할 수는 있지만(RequiredParameters는 정의되지 않음 유형임) 이 모듈이 권한 있는 모드에서 컴파일된다는 점을 고려해야 합니다. 액세스 권한을 제어하지 않습니다. 두 번째 요점은 시스템이 출시될 것인지 아직 100% 확신할 수 없다는 것입니다. 갑자기 애플리케이션 모듈에 오류가 발생하여 데이터베이스로 일부 작업을 수행하려고 합니다.

공통 모듈

모듈은 다른 구성 모듈에서 호출되는 몇 가지 일반적인 알고리즘을 설명하기 위한 것입니다. 일반 모듈에는 변수 설명 섹션과 기본 프로그램 섹션이 포함되어 있지 않습니다. 내보내기 메소드를 선언할 수 있으며, 접근성 컨텍스트는 컴파일 플래그에 의해 결정됩니다. 변수 설명 부분이 없기 때문에 공통 모듈에서는 전역 변수를 정의할 수 없습니다. 이렇게 하려면 반환 값 캐싱이 포함된 일반 모듈의 기능이나 애플리케이션 모듈을 사용해야 합니다. 공유 모듈 재사용 속성이 "세션 기간 동안"으로 설정되어 있더라도 이 경우 캐시된 값의 수명은 마지막 액세스 순간부터 20분을 초과하지 않는다는 점을 명심할 가치가 있습니다. 그들을.
공통 모듈의 동작은 매개변수 세트(전역 여부, 다양한 컴파일 플래그, 서버 호출 사용 가능 여부 등)에 따라 달라집니다. 이 문서에서는 속성 플래그를 부당하게 설정할 때 발생하는 모든 종류의 설정과 동작 기능 및 함정을 고려하지 않습니다. 이것은 별도의 기사에 대한 주제입니다. 플래그를 설정할 때 따라야 할 몇 가지 사항에 대해 살펴보겠습니다.

경험상 좋은 규칙은 전역 플래그를 모든 곳에서 사용하지 않는 것입니다. 이렇게 하면 애플리케이션의 시작 시간이 줄어들고 코드 가독성도 향상됩니다(물론 공통 모듈에 완전히 의미 있는 이름이 있는 경우).
둘 이상의 컴파일 플래그를 사용하는 것은 바람직하지 않습니다. 서로 다른 컨텍스트에서 실행해야 하는 메서드는 많지 않으며, 이러한 메서드가 여전히 필요한 경우 별도의 공통 모듈을 할당할 수 있습니다.
"서버 호출" 플래그는 모듈이 "서버에서" 컴파일된 경우에만 의미가 있습니다. 따라서 다양한 문제를 방지하려면 다른 모든 컴파일 플래그를 제거해야 합니다.
모듈 방법에 대규모 데이터 처리, 데이터베이스 읽기 및 쓰기가 포함되는 경우 작업 속도를 높이려면 "권한" 플래그를 설정하여 액세스 제어를 비활성화하는 것이 좋습니다. 이 모드는 서버에서 컴파일된 공유 모듈에만 사용할 수 있습니다.

양식 모듈

사용자 작업을 처리하도록 설계되었습니다. 데이터 입력 및 입력의 정확성 처리와 관련된 다양한 이벤트. 일반적인 형식의 모듈은 클라이언트에서 완전히 컴파일됩니다. 관리되는 양식 모듈은 실행 컨텍스트에 따라 명확하게 구분되므로 모든 변수와 메서드에는 컴파일 지시문이 있어야 합니다. 지시어가 명시적으로 지정되지 않은 경우 이 변수 또는 메서드는 서버측에서 컴파일됩니다. 양식 모듈에는 변수 및 메소드에 대한 설명 섹션과 기본 프로그램에 대한 섹션이 포함되어 있습니다.

개체 모듈

이 모듈은 많은 구성 개체에 일반적이며 일반적으로 개체 이벤트를 처리하기 위한 것입니다. 예를 들어 객체 기록 및 삭제 이벤트, 문서 게시 이벤트 등이 있습니다.

일부 개체 모듈 이벤트는 양식 모듈 이벤트를 복제합니다. 예를 들어 녹음과 관련된 이벤트입니다. 그러나 양식 모듈 이벤트는 개체의 특정 양식에서만 실행된다는 점을 이해하십시오. 일반적으로 이러한 형태는 여러 가지가 있을 수 있습니다. 그리고 개체 모듈의 이벤트는 개체에 대한 프로그래밍 작업을 수행하는 순간에도 호출됩니다. 따라서 모든 경우에 일부 코드를 실행해야 하는 경우 이를 위해 개체 모듈 이벤트를 사용하는 것이 좋습니다.

개체 모듈은 서버에서만 컴파일됩니다. 여기서는 다른 구성 모듈에서 사용할 수 있는 내보내기 변수와 메서드를 정의할 수 있습니다. 이러한 속성과 메서드를 사용하면 개체의 기능을 크게 확장할 수 있습니다.

개체 관리자 모듈

이 모듈은 많은 구성 개체에 대해 존재합니다. 본 모듈의 주요 목적은 라인 입력 시 발생하는 표준 선택 이벤트를 재정의하고 관리자의 기능을 확장하는 것입니다. 모듈은 서버 측에서 컴파일됩니다. 내보내기 속성과 메서드를 정의할 수 있습니다. 관리자의 내보내기 메소드를 호출하는 데에는 객체 자체를 생성할 필요가 없습니다.

위의 모든 항목에 일부 구성 모듈의 그림과 관리형 애플리케이션 모드에서 메서드를 상호 호출하는 방법을 추가할 수 있습니다. 화살표는 해당 메서드를 호출하기 위해 회전할 수 있는 방향을 나타냅니다. 다이어그램에서 볼 수 있듯이 서버 컨텍스트는 완전히 닫혀 있습니다. 그러나 클라이언트 컨텍스트에서는 서버 메소드에 액세스하는 것이 가능합니다.

다이어그램의 기호: O.M. 클라이언트 - 클라이언트 공통 모듈; OM 서버 - 서버 공유 모듈; M.F. 클라이언트 - 양식 모듈의 클라이언트 절차; M.F. 서버 - 양식 모듈의 서버 프로시저입니다.

소프트웨어 모듈에는 시각적 개발 도구가 충분하지 않을 때 시스템이나 사용자의 작업에 특정 방식으로 응답하는 데 필요한 1C 언어의 실행 코드가 포함되어 있습니다. 또한 소프트웨어 모듈에서 자체 방법(절차 및 기능)을 설명할 수도 있습니다.

일반적으로 소프트웨어 모듈은 세 가지 섹션으로 구성됩니다.

변수 선언 영역;
절차 및 기능을 설명하는 영역;
프로그램의 주요 텍스트.

소프트웨어 모듈 구조의 예:

//********************* 변수 선언 영역 **********************

Perem 성 수출; / /이것은 전역 변수입니다
이름 변경, 후원자; //이것은 모듈 변수입니다
페렘 이름; //이것은 또한 모듈 변수이고 접근될 수 있습니다

//우리 모듈의 모든 프로시저와 기능에서

//***************** 영역 절차 및 기능 설명 ****************

절차 절차1 ()
변동 합계 ; / /Result는 지역 변수(프로시저 변수)입니다.

총계 = 성 + " "+ 이름 + " "+ 중간 이름;

절차 종료

기능 기능1()

// 함수 연산자

Return(성 + " "+ 이름);

EndFunction

//********************* 프로그램의 주요 텍스트 ***********************

성 = "이바노프";
이름 = "이반";
Patronymic = "이바노비치";

//******************************************************************************

특정 소프트웨어 모듈에서는 일부 영역이 누락될 수 있습니다.
변수 선언 영역모듈 텍스트의 시작 부분부터 첫 번째 프로시저나 함수 문 또는 실행 가능한 문까지 배치됩니다. 이 섹션에는 Variable 변수 선언문만 포함될 수 있습니다.

절차 및 기능을 설명하는 영역첫 번째 프로시저 또는 함수 문부터 프로시저 또는 함수 설명 본문 외부의 실행 가능한 문까지 배치됩니다.

메인 프로그램 텍스트 영역프로시저 또는 함수 본문 외부의 첫 번째 실행문부터 모듈 끝까지 배치됩니다. 이 섹션에는 실행 가능한 명령문만 포함될 수 있습니다. 프로그램의 메인 텍스트 영역은 모듈 초기화 순간에 실행됩니다. 일반적으로 메인 프로그램의 한 섹션에서는 모듈의 프로시저나 함수를 처음 호출하기 전에 할당해야 하는 특정 값으로 변수를 초기화하기 위한 연산자를 배치하는 것이 좋습니다.

소프트웨어 모듈은 특정 운영 알고리즘에 대한 설명이 필요할 수 있는 구성 위치에 있습니다. 이러한 알고리즘은 미리 결정된 상황(예: 디렉토리 양식을 열 때, 대화 상자에서 버튼을 누를 때, 개체를 변경할 때 등)에서 시스템 자체가 호출하는 프로시저나 함수의 형태로 공식화되어야 합니다. .

각 개별 소프트웨어 모듈은 시스템에서 단일 전체로 인식되므로 소프트웨어 모듈의 모든 절차와 기능은 단일 컨텍스트에서 수행됩니다.

모듈 실행 컨텍스트는 클라이언트와 서버로 구분됩니다. 또한 일부 소프트웨어 모듈은 클라이언트 측과 서버 측 모두에서 컴파일될 수 있습니다.

애플리케이션 모듈(관리형 또는 일반)

애플리케이션 모듈은 시스템 시작과 종료 시 초기화되는 이벤트의 프로시저(핸들러)를 설명합니다. 예를 들어, 애플리케이션이 실행되기 시작하면 일부 구성 데이터를 업데이트할 수 있고 애플리케이션을 종료할 때 프로그램을 종료할 가치가 있는지 물어볼 수 있습니다. 또한 이 모듈은 거래 또는 회계와 같은 외부 장비의 이벤트를 가로챕니다. 애플리케이션 모듈은 애플리케이션이 대화형으로 실행될 때만, 즉 프로그램 창이 실행될 때만 실행된다는 점은 주목할 가치가 있습니다. 응용프로그램이 com 연결 모드에서 실행되는 경우에는 이런 일이 발생하지 않습니다.
1C 8 플랫폼에는 두 가지 서로 다른 애플리케이션 모듈이 있습니다. 이는 일반 애플리케이션 모듈과 관리형 애플리케이션 모듈입니다. 다른 클라이언트가 시작될 때 트리거됩니다. 따라서 관리되는 애플리케이션 모듈은 웹 클라이언트, 씬 클라이언트 및 씩 클라이언트가 관리되는 애플리케이션 모드에서 실행될 때 트리거됩니다. 그리고 일반 애플리케이션 모드에서 씩 클라이언트가 시작되면 일반 애플리케이션 모듈이 트리거됩니다. 애플리케이션 시작 모드 설정은 "기본 시작 모드" 구성 속성에 지정됩니다.

애플리케이션 모듈에는 변수 선언, 프로시저 및 함수 설명, 프로그램의 기본 텍스트 등 세 가지 섹션이 모두 포함될 수 있습니다. 애플리케이션 모듈은 클라이언트 측에서 컴파일되므로 많은 데이터 유형의 사용이 크게 제한됩니다. "서버 호출" 속성이 설정된 공통 모듈의 메서드를 사용하여 애플리케이션 모듈 컨텍스트를 확장할 수 있습니다. 내보내기로 표시된 모든 애플리케이션 모듈 변수 및 메소드는 클라이언트 측에서 실행되는 모든 구성 모듈에서 사용할 수 있습니다. 그러나 유혹적일 수 있지만 여기에 많은 프로시저와 기능을 배치해서는 안 됩니다. 특정 모듈에 코드가 많을수록 컴파일 시간이 길어지고 결과적으로 애플리케이션 실행 시간도 길어집니다.

위에서 언급한 것처럼 애플리케이션 모듈은 애플리케이션 시작 및 종료 이벤트를 처리합니다. 애플리케이션 모듈에서 이러한 각 이벤트를 처리하기 위해 Before... 및 When... 핸들러 쌍이 있습니다. 두 핸들 간의 차이점은 다음과 같습니다. Before... 핸들러에서 코드를 실행할 때 작업이 아직 수행되지 않았습니다. 발생했으며 당사는 이를 거부할 수 있습니다. 이것이 거부 옵션의 목적입니다. On.. 핸들러에서는 작업이 이미 수행되었으며 애플리케이션 실행을 거부하거나 종료할 수 없습니다.

외부접속모듈

3개 영역을 모두 포함할 수 있습니다.
구성의 루트 섹션에 위치

모듈의 목적은 애플리케이션 모듈의 목적과 유사합니다. 애플리케이션의 시작 및 종료 이벤트를 처리합니다. 외부 연결 모듈은 애플리케이션이 com 연결 모드에서 실행될 때 트리거됩니다. 외부 조인 프로세스 자체는 대화형 프로세스가 아닙니다. 이 모드에서는 정보 기반을 사용한 프로그래밍 작업이 발생하고 응용 프로그램 창이 열리지 않으므로 대화형 작업을 위한 메서드 사용에 특정 제한이 적용됩니다. 이 모드에서는 대화 상자 양식 호출, 사용자에게 보내는 경고 및 메시지 등을 사용할 수 없습니다. 그들은 단순히 처형되지 않을 것입니다.

애플리케이션 모듈에서와 마찬가지로 여기에서는 변수 선언, 프로시저 및 기능 설명, 프로그램의 기본 텍스트 등 세 가지 영역을 모두 사용할 수 있습니다. 애플리케이션 모듈과의 주요 차이점은 com-connection 모드에서는 정보베이스에 대한 모든 작업이 서버 측에서 발생하므로 외부 연결 모듈은 서버 측에서 컴파일된다는 것입니다. 따라서 일반 클라이언트 모듈의 내보내기 변수 및 메소드를 사용할 수 없습니다.

세션 모듈

서버 측에서 실행
구성의 루트 섹션에 위치

이는 세션 매개변수 초기화 전용으로 설계된 고도로 전문화된 모듈입니다. 왜 이를 위해 자체 모듈을 만들어야 했나요? 이를 사용하는 이유는 애플리케이션 자체가 다양한 모드에서 실행될 수 있고(관리되는 애플리케이션 모듈, 일반 애플리케이션 모듈 또는 외부 연결 모듈이 실행됨) 세션 매개변수의 초기화가 관계없이 수행되어야 하기 때문입니다. 시작 모드의. 이 세 가지 모듈 모두에서 동일한 프로그램 코드를 작성하지 않으려면 애플리케이션 시작 모드에 관계없이 실행되는 추가 모듈이 필요했습니다.

세션 모듈에는 응용 프로그램 모듈 이벤트 BeforeSystemStartOperation 이전에도 가장 먼저 실행되는 단일 이벤트 "SettingSessionParameters"가 있습니다. 변수 선언 섹션과 기본 프로그램 섹션을 사용할 수 없습니다. 내보내기 방법도 선언할 수 없습니다. 모듈은 서버 측에서 컴파일됩니다.

공통 모듈

절차와 기능을 설명하는 영역을 포함할 수 있습니다.
서버 또는 클라이언트 측에서 실행됨(모듈 설정에 따라 다름)
구성 개체 "일반" - "일반 모듈"의 트리 분기에 있습니다.

공통 모듈은 다른 구성 모듈에서 호출되는 몇 가지 공통 알고리즘을 설명하기 위한 것입니다. 일반 모듈에는 변수 선언 영역과 기본 프로그램 텍스트가 포함되어 있지 않습니다. 내보내기 방법을 선언할 수 있으며, 그 가용성은 모듈 설정(실행되는 쪽: 서버 또는 클라이언트 쪽)에 따라 결정됩니다. 변수 설명 부분이 없기 때문에 공통 모듈에서는 전역 변수를 정의할 수 없습니다. 이를 위해 애플리케이션 모듈을 사용할 수 있습니다.

공통 모듈의 동작은 매개변수 세트(전역 여부, 다양한 컴파일 플래그, 서버 호출 사용 가능 여부 등)에 따라 달라집니다. 다음은 공통 모듈 설정에 대한 몇 가지 팁입니다.

어디에서나 글로벌 플래그를 사용하지 않는 것이 좋습니다. 이렇게 하면 애플리케이션의 시작 시간이 줄어들고 코드 가독성도 향상됩니다(물론 공통 모듈에 완전히 의미 있는 이름이 있는 경우).
- 하나 이상의 컴파일 플래그를 사용하는 것은 바람직하지 않습니다. 다양한 컨텍스트에서 실행해야 하는 메서드는 많지 않으며, 이러한 메서드가 여전히 필요한 경우 별도의 공통 모듈을 할당할 수 있습니다.
- "Call server" 플래그는 모듈이 "On the server"로 컴파일된 경우에만 의미가 있습니다. 따라서 다양한 문제를 방지하려면 다른 모든 컴파일 플래그를 제거해야 합니다.
- 모듈 방법에 대규모 데이터 처리, 데이터베이스 읽기 및 쓰기가 포함되는 경우 작업 속도를 높이려면 "권한" 플래그를 설정하여 액세스 제어를 비활성화하는 것이 좋습니다. 이 모드는 서버에서 컴파일된 공유 모듈에만 사용할 수 있습니다.

양식 모듈

3개 영역을 모두 포함할 수 있습니다.
서버측과 클라이언트측에서 실행됨

양식 모듈은 이 양식을 사용하여 사용자 작업(버튼 클릭 이벤트 처리, 양식 세부정보 변경 등)을 처리하도록 설계되었습니다. 양식 자체와 직접적으로 연관된 이벤트도 있습니다(예: 양식 열기 또는 닫기). 관리되는 양식과 일반 양식의 모듈은 우선 관리되는 양식의 모듈이 컨텍스트로 명확하게 구분된다는 점에서 다릅니다. 모든 프로시저나 함수에는 컴파일 지시문이 있어야 합니다. 컴파일 지시어가 지정되지 않은 경우 이 프로시저나 함수는 서버측에서 실행됩니다. 일반적인 형태에서는 모든 코드가 클라이언트 측에서 실행됩니다.

관리되는 폼의 구조에는 변수 선언 섹션, 프로시저 및 함수 설명, 프로그램의 기본 텍스트(폼 초기화 시 실행됨)가 포함됩니다. 양식의 예상 절차 및 기능 목록을 통해 표준 양식 이벤트에 액세스할 수 있습니다. (Ctrl+Alt+P), 또는 양식 자체의 속성 팔레트를 통해.

양식에 기본 속성이 할당되어 있으면 기본 속성으로 사용되는 애플리케이션 개체의 속성과 메서드를 양식 모듈에서 사용할 수 있게 됩니다.

개체 모듈

3개 영역을 모두 포함할 수 있습니다.
서버 측에서 실행

이 모듈은 대부분의 구성 개체에 사용할 수 있으며 일반적으로 개체와 직접 관련된 이벤트를 처리하기 위한 것입니다. 예를 들어 객체 기록 및 삭제 이벤트, 객체 내역 완료 확인, 문서 게시 등의 이벤트가 있습니다.

일부 개체 모듈 이벤트는 양식 모듈 이벤트를 복제합니다. 예를 들어 녹음과 관련된 이벤트입니다. 그러나 폼 모듈의 이벤트는 해당 객체의 특정 폼, 즉 특정 폼이 열릴 때 독점적으로 실행된다는 점을 이해해야 합니다. 그리고 개체 모듈의 이벤트는 개체에 대한 프로그래밍 작업을 수행하는 순간에도 호출됩니다. 따라서 객체의 특정 형태에 얽매이지 않고 객체와 관련된 메서드가 필요한 경우 이를 위해 객체 모듈을 사용하는 것이 좋습니다.

개체 관리자 모듈

3개 영역을 모두 포함할 수 있습니다.
서버 측에서 실행

개체 관리자 모듈은 버전 1C 8.2부터만 나타났습니다. 관리자 모듈은 모든 애플리케이션 개체에 대해 존재하며 이 개체를 구성 개체로 관리하도록 설계되었습니다. 관리자 모듈을 사용하면 데이터베이스 개체의 특정 인스턴스가 아닌 구성 개체 자체와 관련된 프로시저 및 기능을 도입(작성)하여 개체의 기능을 확장할 수 있습니다. 개체 관리자 모듈을 사용하면 특정 개체에 대한 공통 프로시저와 함수를 배치하고 처리 등 외부에서 해당 항목에 액세스할 수 있습니다(물론 이 프로시저나 함수에 내보내기 키워드가 있는 경우). 이것이 우리에게 어떤 새로운 것을 주는가? 일반적으로 절차를 개체별로 구성하고 별도의 장소(개체 관리자 모듈)에 저장하는 것 외에는 아무것도 없습니다. 이러한 절차와 기능을 일반 모듈에 성공적으로 배치할 수 있지만 1C에서는 개체 관리자 모듈에 개체의 일반 절차와 기능을 배치하는 것이 좋습니다. 개체 관리자 모듈의 절차 및 기능 사용 예: 특정 조건에서 디렉터리 또는 문서의 개별 세부 정보를 처음 작성하고, 특정 조건에서 디렉터리 또는 문서의 세부 정보가 완료되었는지 확인하는 등.

명령 모듈

절차와 기능을 설명하는 섹션이 포함될 수 있습니다.
클라이언트 측에서 실행됨

명령은 응용 프로그램 개체 또는 전체 구성에 종속된 개체입니다. 각 명령에는 해당 명령을 실행하기 위해 미리 정의된 CommandProcess() 프로시저를 설명할 수 있는 명령 모듈이 있습니다.

1C:Enterprise 시스템 구성의 새 버전에서는 많은 기능과 절차가 개체 모듈(문서, 디렉터리 등)에서 관리자 모듈로 이동했습니다. 두 모듈의 차이점을 살펴보겠습니다.

객체지향 프로그래밍 이론에 따르면 객체 메소드는 정적 메소드와 단순 메소드의 두 그룹으로 나뉩니다. 간단한 메서드는 클래스의 특정 인스턴스에만 액세스할 수 있습니다. 정적 메서드는 개체 데이터에 액세스할 수 없지만 클래스 전체와 함께 작동합니다.

이 모든 것을 1C:Enterprise 시스템의 용어로 번역하면 개체 모듈간단한 방법이 포함되어 있습니다. 이를 사용하려면 먼저 특정 개체(디렉토리, 문서 등의 요소)를 얻어야 합니다. 관리자 모듈정적 메소드를 포함합니다. 이를 사용하려면 각 특정 개체를 별도로 얻을 필요가 없으며 전체 컬렉션을 한 번에 작업할 수 있습니다.

개체 모듈외부에서 사용할 수 있는 프로시저와 기능이 있을 수 있습니다. 이를 위해 그러한 절차나 기능은 다음과 같은 단어로 표시됩니다. 내보내다.

함수 NewFunction() 내보내기

개체 모듈에서 이러한 기능을 사용하려면 먼저 필요한 개체에 대한 링크가 있어야 하며, 해당 기능을 사용하여 해당 개체를 가져와야 합니다. GetObject().

당 = 개체. 새로운함수() ;

마찬가지로 다양한 구성 개체에서 사용할 수 있는 새 변수를 만들 수 있습니다.

변수 새변수 내보내기

디렉토리 요소 = 디렉토리. 명명법. FindByCode("000000001" ) ;
개체 = 디렉터리 요소. GetObject() ;
객체. 새로운변수= ) ;

이러한 방식으로 개체의 표준 절차, 기능 및 속성(변수)을 보완할 수 있습니다. 이러한 변수는 동적이며 정보베이스에 저장되지 않으며 수신된 개체로 작업하는 동안에만 존재합니다.

관리자 모듈모두 동일한 기능을 가지고 있지만 유일한 차이점은 이를 사용하기 위해 특정 개체를 얻을 필요가 없다는 것입니다. 관리자 모듈을 사용하면 특정 유형의 전체 개체 컬렉션에 대해 작업할 수 있습니다.

프로시저 NewProcedure() 내보내기

디렉토리 요소 = 디렉토리. 명명법. 새로운프로시저();

또는 변수의 경우:

변수 새변수 내보내기

디렉토리 요소 = 디렉토리. 명명법. 새로운변수;

인쇄된 문서를 생성하는 과정의 예를 통해 객체 모듈과 관리자 모듈의 사용 차이점을 살펴보겠습니다.

개체 모듈을 사용할 때 코드는 다음과 같습니다.

기능 인쇄 문서(링크) 내보내기
//이 함수에는 특정 문서에 대한 링크를 전달해야 합니다.
TabDoc을 반환합니다.
EndFunction

문서 양식에서 문서에 대한 링크를 인쇄 기능에 전달하는 프로시저를 만들어야 합니다.

&On클라이언트
절차 인쇄(명령)
TabDoc = PrintOnServer();
TabDoc. 보여주다() ;
절차 종료
&서버에서
함수 PrintOnServer()
Doc = FormAttributesValue("객체" ) ;
문서를 반환합니다. PrintDocument(Object.Link) ;
EndFunction

이 방법의 단점은 하나의 개체만 인쇄한다는 것입니다. 한 번에 여러 문서를 인쇄해야 하는 경우 각 문서를 가져온 다음 개체 모듈에서 함수를 호출해야 합니다. 개체를 검색할 때 전체 개체가 RAM에 배치되기 때문에 상당한 시스템 리소스가 필요합니다.

성능 관점에서 볼 때 가능하면 관리자 모듈을 사용하는 것이 훨씬 좋습니다. 이 예에서 문제에 대한 해결책은 다음과 같습니다.
함수 PrintOnServer()
문서를 반환합니다. 우리의 문서. PrintDocument(ArrayLinks);
EndFunction

관리자 모듈을 사용하는 경우 문서 양식과 목록 양식 모두에서 인쇄 프로시저를 호출하여 배열의 여러 문서에 대한 링크를 전달할 수 있습니다. 이 경우 시스템은 어레이에서 각 문서를 가져올 필요가 없으므로 시스템 리소스가 크게 절약됩니다.

그렇다면 언제 객체 모듈을 사용하고 언제 관리자 모듈을 사용합니까?

그것은 모두 작업에 따라 다릅니다. 객체에 대한 참조만으로 객체를 완료할 수 있다면(예: 인쇄 작업) 관리자 모듈을 사용하는 것이 더 좋습니다. 예를 들어 문서 작성과 같이 데이터를 변경하는 작업인 경우 해당 데이터를 가져와 개체 모듈을 사용해야 합니다.