2008-08-25 9 views

답변

18

코드의 어느 부분에서나 사용할 수있는 범위는 세션, 클라이언트, 쿠키, 응용 프로그램 및 요청입니다. 일부는 사용자 정의 태그 또는 CFC 내부의 요청 또는 응용 프로그램 범위 (예 : coupling)를 사용하여 캡슐화 원칙에 위배되며 나쁜 관행으로 간주되는 특정 방식으로 사용하는 것은 좋지 않습니다. 일부는 특별한 목적을 가지고 있습니다. 쿠키는 클라이언트에서 유지됩니다 시스템을 실제 쿠키로 사용하고 세션 범위 변수는 사용자별로 다르고 웹 사이트에서 사용자의 세션으로 만료됩니다.

변수가 변경 될 가능성이 매우 낮고 (모든 용도와 목적에 대해 상수 임) 응용 프로그램 시작시 간단히 초기화 할 수 있고 다시 작성하지 않으면 일반적으로 모든 사용자와 모든 사용자간에 유지되므로 응용 프로그램 범위에 넣어야합니다 세션. 제대로 구현되면, 한번 쓰고 N 번 읽는다.

으로 Application.cfm에서 응용 프로그램 변수의 적절한 구현은 다음과 같습니다 응용 프로그램 범위 변수의 존재, 그래서 전에 잠금 후 선택되어 있는지

<cfif not structKeyExists(application, "dsn")> 
    <cflock scope="application" type="exclusive" timeout="30"> 
     <cfif not structKeyExists(application, "dsn")> 
      <cfset application.dsn = "MyDSN" /> 
      <cfset foo = "bar" /> 
      <cfset x = 5 /> 
     </cfif> 
    </cflock> 
</cfif> 

참고 그 두 명의 사용자가있는 경우 응용 프로그램 시작시 경쟁 조건을 만들면 그 중 하나만 응용 프로그램 변수를 설정하게됩니다.

이 방법의 장점은 모든 요청에서 이러한 저장된 변수를 지속적으로 새로 고치지 않아 사용자의 시간과 서버의 처리주기가 낭비된다는 것입니다. 단점은 다소 장황하고 복잡하다는 것입니다.

Application.cfc를 추가하면 크게 간단 해졌습니다. 의 모든 포함 Application.cfc에 대한 자세한 내용은

<cfcomponent> 
    <cfset this.name = "myApplicationName" /> 

    <cffunction name="onApplicationStart" returnType="boolean" output="false"> 
     <cfset application.dsn = "MyDSN" /> 
     <cfset foo = "bar" /> 
     <cfset x = 5 /> 
     <cfreturn true /> 
    </cffunction> 
</cfcomponent> 

: 지금, 당신은 응용 프로그램 시작에 생성되고 잠금 및 존재 여부를 확인하고 그 재미있는 모두에 대해 걱정하지 않아도되는 변수를 지정할 수 있습니다 사용할 수있는 다양한 특수 기능과 사용 방법 및 사용 방법에 대한 세부 정보가 모두 제공됩니다 (I recommend this post on Raymond Camden's blog).

요약하면 요청 범위는 코드의 모든 부분에서 사용할 수 있지만 모든 곳에서 사용할 수있는 "올바른"요구 사항은 아닙니다. 기회는 당신의 전임자가 캡슐화를 깨기 위해 그것을 사용하고 있었고 그것은 리팩터링하는 것이 번거로울 수 있습니다. 있는 그대로 그대로 두는 것이 가장 좋지만 어떤 범위가 작업에 가장 적합한 도구인지 이해하는 것이 향후 코드를 더 좋게 만듭니다.

15

이것은 매우 주관적인 질문이며 현대 ColdFusion 응용 프로그램에서 요청 범위를 사용하는 것이 결코 "적절하지 않다고 주장하는 사람도 있습니다.

그런 면책 조항을 제외하고 요청 범위가 무엇이며 어디에서 유용 할 지 정의 해 봅시다.

요청 범위는 단일 ColdFusion 페이지 요청의 절대 전역 범위입니다. 응용 프로그램, 서버, 클라이언트 및 세션 범위와 같은 공유 범위가 아니므로 CF8의 CFTHREAD 태그를 사용하여 단일 요청에서 작업자 스레드를 생성하지 않는 한 잠금은 스레드 안전을 보장 할 필요가 없습니다. 전역 범위로서 부모에서 호출자로 변수를 전달하지 않고도 요청 스택의 모든 레벨을 통해 변수를 유지하는 매우 편리한 방법입니다. 이는 오래된 CF 응용 프로그램에서 중첩 된 또는 재귀 적 사용자 정의 태그를 통해 변수를 유지하는 매우 일반적인 방법이었습니다.

많은 응용 프로그램이 응용 프로그램 수준 변수 (예 : 구성 설정)를 저장하는 데이 범위를 사용하지만 요청 범위와 응용 프로그램 범위 사이의 큰 차이 (경우에 따라 미묘함)는 동일한 요청 범위가 지정된 변수는 개별 페이지 요청마다 다를 수 있습니다.

나는 당신의 전임자 편리 주위에 명시 적으로 전달하지 않고 코드의 캡슐화 또는 중첩 단위 사이의 점프를 살아 남기 위해 필요한 변수를 설정하기위한 수단으로이 범위를 사용했다고 생각합니다.

0

좋아, 난 그냥 코드에 대해 언급하고 싶었다. 미쳤다면 용서해주세요. 그러나 당신은 이미 structKeyExists가 시작 부분에 있는지 확인했다. 그것이 사실 일 것이라는 것을 알고 있기 때문에 다른 수표를 발행하는 것은 의미가 없습니다. 그래서 내 버전은 이것 일거야 ...하지만 그건 나 뿐이야.


<cfif not structKeyExists(application, "dsn")> 
    <cflock scope="application" type="exclusive" timeout="30"> 
      <cfset application.dsn = "MyDSN" /> 
      <cfset foo = "bar" /> 
      <cfset x = 5 /> 
    </cflock> 
</cfif> 

좋아

.

+0

모범 사례에서는 경쟁 조건을 피하기 위해 cflock에서 다시 확인해야합니다. –

+2

CFMX6.0은 CFLOCK을 사용하기 때문에 응용 프로그램 범위 변수를 설정하는 데 "우수 사례"가 없으므로 경쟁 조건이 발생할 가능성이 있습니다 코드는 여기에 제공됩니다. 응용 프로그램 범위의 변수에 간단한 값을 설정하고 전체 프로세스가 원자 단위 (예 : 하나의 명령문이며이 예와 같이 경쟁 조건의 범위가없는 경우) 인 경우 CFPARAM 태그를 사용하는 것만으로 벌금. –

0

나는 우리의 사이트에 전원을 공급하는 데 사용됩니다 내 회사의 프레임 워크를 작성했습니다.

요청 변수를 사용하여 다른 CFC에서 사용할 수있는 특정 데이터를 설정 했으므로 데이터를 계속 전달할 필요없이 애플리케이션에서 사용할 수 있도록 데이터를 사용할 수있었습니다. 나는 솔직히 그 요청을 사용하여 응용 프로그램과 같은 정적 함수 구성 요소로 다음 당신은 문제가 없어야한다고 믿습니다. 나는 내 사고 방식이 틀리면 잘 모르겠지만 일단 우리가 볼 프레임 워크를 공개하면됩니다.