ASP 응용 프로그램의 성공은 일반적으로 아키텍처와 디자인의 상충 관계에 달려 있습니다. 광범위한 ASP 기술과 현재 응용 프로그램의 고유 한 복잡성을 고려할 때이 트레이드 오프는 매우 어렵습니다. 다음은 잘못된 신기술 채널에서 ASP의 원칙과 사용에 대한 간략한 소개입니다.
명명 규칙을 설정하고 디렉토리 구조를 표준화하면 ASP 응용 프로그램의 가독성과 유지 가능성을 크게 향상시킬 수 있습니다. 현재 ASP 응용 프로그램에 대한 공식적인 표준은 없지만 많은 개발자들이 몇 가지 일반적인 방법을 설정했습니다. 여기, 나는 당신과 몇 가지 일반적인 방법을 나누겠습니다.
ASP 기술은 스크립트 엔진에 의존하고 스크립트는 유형이 엄격하지 않다는 특성이 있기 때문에 이름 지정 규칙도 모호합니다. 매우 엄격한 유형의 언어에서는 변수가 실제 유형에 따라 선언됩니다. ASP 기술을 사용하는 경우 변수는 일반적으로 실제 데이터 유형이 아닌 변수를 처리하는 방식으로 ASP 코드로 선언됩니다. 예를 들어, "Visual Basic (R) 스크립팅 에디션 (vbscript)"을 사용할 때 모든 vbscript 변수는 변형이지만 성공 플래그는 vSuccess (v 변형) 대신 bsuccess (b에 대한 b)로 선언합니다.
다음 표는 몇 가지 일반적인 이름 지정 규칙입니다.
가변 접두사 :
| 접두사 | 사용 된 변수 | 변수 예 |
|---|---|---|
| b 또는 bln | 부울 | bsuccess |
| C 또는 CUR | 통화 | 카운트 |
| D 또는 DBL | 더블 | dblquantity |
| DT 또는 DAT | 날짜와 시간 | dtdate |
| f 또는 flt | 뜨다 | Fratio |
| l 또는 lng | 긴 | lmilliseconds |
| 나 또는 int | 정수 | 아이언터 |
| s 또는 str | 끈 | 저격 |
| A 또는 ARR | 정렬 | ausers () |
| o 또는 obj | com 객체 | opipleline |
데이터베이스 개체의 변수 접두사 :
| 접두사 | 사용 된 변수 | 변수 예 |
|---|---|---|
| CNN | 연결 | CNNPUBS |
| rst | 레코드 세트 | rsstauthors |
| CMD | 명령 | cmdemployee |
| FLD | 필드 | fldlastname |
범위 및 접두사 사용 :
| 접두사 | 설명 |
|---|---|
| g_ | Global.asa에서 만들어졌습니다. |
| 중_ | ASP 페이지 또는 포함 파일의 경우 로컬입니다. |
| (접두사 없음) | 비 정적 변수, 접두사는 프로세스에 로컬입니다 |
KB (Knowledge Base)의 게시물 "Q110264 정보 : Microsoft Consulting Services Niming Conventions for Visual Basic"(영어)는 이름 지정 규칙에 대한 통찰력을 제공합니다.
가능한 경우 디렉토리 구조를 사용하여 다양한 응용 프로그램 구성 요소에 일관된 위치를 제공하십시오. 응용 프로그램의 실제 디렉토리 구조는 물론 귀하에게 달려 있지만 일반적으로 이미지, 문서, 파일 및 구성 요소를 별도의 디렉토리에 배치하는 것입니다. 다음은 간단한 ASP 응용 프로그램 디렉토리 구조의 예입니다.
디렉토리 구조 예 :
/simpleaspapp /docs /images /contuary
좋은 디렉토리 구조를 사용하면 NTFS 권한을 선택적으로 적용 할 수 있습니다. ASP 응용 프로그램 내에서 상대 경로를 사용할 수도 있습니다. 예를 들어, 다음 코드를 사용하여 default.asp 페이지의 포함 디렉토리에있는 포함 파일 위에 참조 할 수 있습니다.
./includes/top.asp
내 포함 된 파일의 확장은 .inc가 아닌 .asp입니다. 이는 보안상의 이유로 이루어지며 .ASP 확장 (.inc가 아닌)을 사용하며 Visual Interdev (R)에서 색상 인코딩도 가능합니다.
구조화 된 ASP 응용 프로그램에 대한 다른 팁과 팁은 "ASP 컨벤션"기사 (영어)를 참조하십시오.
ASP는 서비스하에 실행됩니다. ASP 응용 프로그램을 설계 할 때는 즉시 데스크탑 응용 프로그램에서 발생하지 않는 보안 환경 및 스레딩 문제에 직면하게됩니다. 데스크탑 환경에서는 대화식 사용자로서 단일 스레드 실행 만 실행되면 일반적으로 처리되며 현재 데스크톱 시스템에 액세스 할 수 있습니다. 인터넷 정보 서비스 (IIS)에서 다양한 사용자 환경의 여러 클라이언트 스레드가 응용 프로그램을 호출하도록 시뮬레이션되며 응용 프로그램은 "시스템"데스크탑으로 제한됩니다.
이것이 당신에게 무엇을 의미합니까? IIS의 안전 모드를 배우십시오. 또한 시각적 기본 IDE에서 무언가가 제대로 실행될 수 있다고해서 ASP 기술에서 안전하게 실행될 수 있다는 의미는 아닙니다. Visual Basic IDE는 런타임 환경을 정확하게 시뮬레이션하지 않습니다. 일반적인 설계 오류에는 ASP 기술에서 사용자 인터페이스가 필요한 .ocx 컨트롤 사용, 스레드에 안전하지 않은 구성 요소를 사용하고 특수 사용자 컨텍스트가 필요한 구성 요소를 사용하는 것이 포함됩니다. 피하는 가장 쉬운 문제 중 하나는 응용 프로그램에서 HKey_Current_User (HKCU) 레지스트리 키에 액세스하는 것입니다 (예 : Visual Basic의 GetSetting 및 SaveSetting 함수를 호출하지 마십시오. 마찬가지로, 사용자가 휴머 컴퓨터와 상호 작용하도록 요구하는 메시지 상자 나 다른 대화 상자가 나타나지 마십시오.
다음 기사는 ASP 기술의 보안 및 검증 문제에 대한 매우 좋은 입문서입니다.
ASP 기술은 HTML 출력을 생성하여 표현 서비스를 제공합니다. 요컨대, 사용자 인터페이스를 생성합니다. ASP 표현 스크립트와 비즈니스 로직을 분리해야합니다. COM 구성 요소를 사용하여 비즈니스 로직을 ASP 코드와 분리하지 않더라도 최소한 비즈니스 로직을 기능으로 별도로 별도로 분리하고 유지 관리 가능성, 가독성 및 재사용 가능성을 향상시키기위한 파일을 포함합니다. 문제 해결 및 격리 문제가 필요할 때 모듈 식 설계 방법의 이점을 이해할 수도 있습니다.
스크립트 내부의 기능 및 메소드를 호출하면 코드를 엉망으로 만들지 않고 ASP 응용 프로그램에 구조를 추가 할 수 있습니다. 다음 예제는 논리를 메소드 호출로 분리하는 방법을 보여줍니다.
lt;% main () mybizmethod () ... sub main () getData () displayData () end sub%>
이 원칙은 ASP 기능을 포함하는 기술을 사용할 때 적용 할 수 있습니다. 다음은 Visual Basic WebClass를 사용할 때이 원칙을 사용하는 방법의 예입니다.
일반적인 문제는 데스크탑 시스템에서 서버로의 전환입니다. 데스크탑 시스템 배경을 가진 많은 개발자들은 서버 문제와 리소스 공유에 대해 걱정하지 않았습니다. 기존 데스크톱 응용 프로그램에서 서버에 연결하는 것은 시간이 많이 걸리는 프로세스입니다. 사용자 경험을 향상시키기 위해 일반적으로 자원을 조기에 획득하고 리소스 출시를 지연시키는 데 사용됩니다. 예를 들어, 많은 응용 프로그램은 실행 시간 동안 항상 데이터베이스에 연결됩니다.
이 방법은 기존 데스크톱 응용 프로그램에서 제대로 작동합니다. 그 이유는 사용자 수가 매우 명확하고 제어하기 쉽고 백엔드와 프론트 엔드가 밀접하게 연결되어 있기 때문입니다. 그러나 현재 웹 애플리케이션의 경우 제한된 서버 리소스가 점점 더 많은 사용자를 대상으로하기 때문에이 접근 방식은 더 이상 실현 가능하지 않습니다. 응용 프로그램이 사용자의 증가에 대처하려면 가능한 한 늦게 자원을 얻고 가능한 빨리 리소스를 릴리스해야합니다.
공유는이 접근법의 효과를 높이는 데 도움이됩니다. 공유를 통해 여러 사용자가 최소 대기 시간과 서버에 미치는 영향으로 리소스를 공유 할 수 있습니다. 예를 들어, 데이터베이스와 함께 작업 할 때 ODBC 연결 공유 및 OLEDB 리소스 공유를 사용하면 공유 풀에서 연결을 선택하여 데이터베이스에 연결하는 오버 헤드를 최소화 할 수 있습니다.
ADO 공유에 대한 자세한 내용은 "Microsoft Data Access 구성 요소의 풀링"을 참조하십시오.
HTTP 프로토콜은 무국적이지만 ASP 개발자는 종종 ASP 기능에 내장 된 상태 보유 메커니즘을 사용합니다. 예를 들어, ASP 기술에 내장 된 응용 프로그램 객체를 사용하면 개발자가 저장 한 리소스를 응용 프로그램의 모든 사용자가 공유 할 수 있습니다. ASP의 내장 세션 객체를 사용하면 개발자는 단일 사용자에게만 리소스를 저장합니다.
ASP 기술의 세션 객체에서 정보를 저장하는 것은 상태를 유지하는 매우 편리한 방법이지만,이 접근법은 너무 비싸고 확장성에 대한 가장 큰 제한 요인 중 하나 일 수도 있습니다. 응용 프로그램의 확장 성은 본질적으로 사용자 수가 증가함에 따라 성능을 계속 유지하는 능력입니다. 각 사용자에 대해 세션 객체는 세션이 시작되거나 포기되기 전에 서버의 리소스를 소비합니다. 세션은 또한 서버에 묶여 웹 클러스터를 활용하는 능력을 제한합니다. 상태 관리를 위해 ASP 세션 객체를 가능한 한 많이 사용하지 마십시오. 세션을 전혀 사용하지 않는 경우 웹 응용 프로그램의 세션 상태를 비활성화 할 수 있습니다 (IIS 문서 참조). 그렇지 않으면 다음 진술을 사용하여 각 페이지의 세션 상태를 비활성화 할 수 있습니다.
< %@enablesessionstate = false %>
간단한 데이터의 경우 QueryString 쿠키 또는 숨겨진 양식 도메인을 사용하여 ASP 요청 간 상태를 유지할 수 있습니다. 그런 다음보다 복잡한 정보를 얻으려면 일반적으로 데이터베이스를 사용하는 것이 좋습니다. 일반적인 접근 방식은 고유 식별자를 생성 한 다음 각 요청 클라이언트에게 보내어 숨겨진 양식 필드로 저장하는 것입니다. 후속 요청 에서이 고유 식별자는 데이터베이스의 사용자와 관련된 상태 정보를 찾는 데 사용됩니다. 이 접근법은 더 높은 확장 성과 간결하고 명확한 코드를 제공합니다.
QueryString 쿠키 및 숨겨진 양식 필드 사용에 대한 자세한 내용은 "Q175167 Howto : 세션없이 지속되는 값"을 참조하십시오.
ASP 기술 객체를 만들 때 선택할 수 있습니다
가능한 예외는 다음과 같습니다. 방화벽을 통해 호출 할 때 Server.createObject 대신 CreateObject를 호출해야 할 수도 있습니다. 자세한 내용은 "Q193230 -PRB : Server.createObject가 방화벽 뒤에있을 때 실패"(영어)를 참조하십시오.
모든 ASP 응용 프로그램에 오류 처리가 포함되어 있는지 확인하십시오. 또한 유용한 진단 정보를 제공하십시오. 오류 메시지가 너무 설명 적이라고 불평하는 사람은 없었습니다. 오류 로그에 다음 정보를 포함 시키십시오.
ASP에서 실행되기 때문에이 정보를 파일 또는 NT의 이벤트 로그에 작성할 수 있습니다. 응용 프로그램 오류를 진단 할 때 사용하기 위해 중요한 응용 프로그램 이벤트를 기록하는 응용 프로그램 이벤트 로그를 만들 수도 있습니다.
다음 기사는 오류 처리 기술에 대한 자세한 정보를 제공합니다.
브라우저는 테스트하는 정확한 방법이 아니며 응용 프로그램의 가능한 사용 만 보여줄 수 있습니다. 응용 프로그램의 특정 성능 목표를 설정하고 스트레스 테스트를위한 웹 응용 프로그램 스트레스 도구와 같은로드 도구를 사용하십시오. 환경이 수용 할 수있는 것을 직접 결정해야하며 테스트 프로세스를 시작하는 데 도움이되는 몇 가지 일반적인 지침이 있습니다.
테스트 환경을 실제 실행 환경과 일치 시키며 방화벽도 예외는 아닙니다. 이것은 비싸지 않지만 개발자들이 방화벽을 고려하지 않기 때문에 일자리를 잃는 것을 들었습니다.
웹 애플리케이션 응력 도구를 사용하여 ASP 응용 프로그램 테스트에 대한 자세한 내용은 "스트레스가 충분하지 않습니다 - ASP 응용 프로그램을로드하십시오"를 참조하십시오.
격리로 애플리케이션 프로세스를 보호하면 서버 안정성을 크게 향상시킬 수 있습니다. 인터넷 응용 프로그램과 관련하여 격리를 사용한 결과는 크게 다를 수 있습니다. 하나는 응용 프로그램 충돌이고 다른 하나는 서버 충돌입니다. 기본 IIS 프로세스 (inetinfo.exe)를 보호하는 것은 일반적으로 우선 순위가 높은 목록에 있습니다. 구성 요소를 사용할 때 특히 두드러집니다.
주요 ISS 프로세스를 보호하기 위해 일반적으로 사용되는 기술은 웹 애플리케이션이 해당 메모리 공간에서 실행할 수 있도록하는 것입니다. 인터넷 서비스 관리자에서는 각 웹 마다이 옵션을 설정할 수 있습니다. 마샬링 프로세스에 압도되는 시스템 리소스는 성능에 약간의 영향을 미치지 만 응용 프로그램에 대한 보호 효과는 비용이 많이 듭니다. IIS 4.0에서는 응용 프로그램 내 프로세스 및 프로세스 외 (OOP)을 실행할 수 있습니다. OOP 응용 프로그램은 새로운 mtx.exe 인스턴스에서 실행됩니다. IIS 5.0에서는 다른 격리 옵션을 사용할 수 있습니다. 분리 레벨은 "낮은"(inetinfo.exe의 과정 내 응용 프로그램), "medium"(dllhost.exe shared instance) 또는 "High"(dllhost.exe의 비 공유 인스턴스)로 설정할 수 있습니다.
자체 메모리 공간에서 웹 응용 프로그램을 분리하는 것 외에도 신뢰할 수없는 구성 요소를 분리 할 수도 있습니다. 신뢰할 수없는 구성 요소는 일반적으로 실제 환경에서 테스트 시간을 통과하지 않는 구성 요소입니다. 이 구성 요소를 서버 패키지에서 실행하여 새로운 dllhost.exe 인스턴스에서 실행할 수 있습니다.
일반적으로 성능과 보호 사이에 적당한 접근 방식을 취하려면 다음과 같은 방법입니다. 웹 응용 프로그램을 "높은"격리 상태로 실행하고 라이브러리 패키지에서 구성 요소를 실행하십시오. 이 접근법은 마샬링 비용을 최소화하면서 프로세스간에 가장 강력한 보호를 제공합니다.
자세한 내용은 "프로세스 격리를 통한 서버 안정성"기사를 참조하십시오.
IIS 4.0에서 ASP의 기본 공통 그룹은 각 MTS 관리 프로세서에 대해 10 개의 스레드입니다. IIS 5.0에서 기본값은 20입니다. 이는 각 스레드가 여러 클라이언트 요청을 처리 할 수있는 잠재적으로 귀중한 리소스임을 의미합니다. 또한 대규모 데이터베이스 호출과 같이 발생할 수있는 차단 방법을 피해야합니다. 이 작업을 수행 할 작업이 있으면 ASP 응용 프로그램이 클라이언트에 대한 응답을 신속하게 반환하지 못하게합니다. 대기열 기능 사용을 고려하십시오. 예를 들어, NT 4.0에서는 MSMQ를 사용할 수 있습니다. Windows 2000에서는 대기열 구성 요소를 사용할 수 있습니다.
세션에 단일 스레드 아파트 (STA) 구성 요소를 저장하지 않는 일반적인 단점 중 하나는 세션 범위에서 시각적 기본 객체를 채우는 것입니다. 스레드별로 그룹을 공유하는 목적에 위배되는 스레드에 사용자를 고정합니다. 잠재적 인 사용자는 다른 사용자 뒤에 차단되어 구성 요소를 생성하는 스레드가 유효 해지기를 기다립니다. 다른 방법을 사용하여 각 페이지를 기반으로 생성 및 파괴 할 수있는 무국적 구성 요소를 설계해야합니다.
빠른 팁 : 서버에서 ASP 스크립트 디버깅 기능이 비활성화되어 있는지 확인하십시오 (인터넷 서비스 관리자 사용). ASP 스크립트 디버깅이 활성화되면 ASP 실행이 스레드에 고정됩니다.
자세한 내용은 다음 기사를 참조하십시오.
ASP 응용 프로그램을 작성하려면 상당한 범위의 지식이 필요합니다. ASP 응용 프로그램의 한 가지 과제는 현재 일반적인 규칙이 없다는 것입니다 (이는 재미의 일부이기도합니다. 또 다른 문제는 많은 개발자들이 인터넷 개발과 접촉하기 전에 데스크탑 시스템 개발에 종사하고 있다는 것입니다. ASP 개발 노력에 위의 규칙을 적용하면 비용이 많이 드는 실수를 피하고 훌륭한 ASP 응용 프로그램을 개발할 수 있기를 희망합니다.
JD Meier는 미국의 동해안에서 태어나고 자랐습니다. Horace Greeley의 조언에 따라 그는 Windows DNA 응용 프로그램뿐만 아니라 MTS 및 ASP 기술을 포함한 서버 측 구성 요소에 중점을 둔 개발자 지원 엔지니어가되었습니다.
The New Technology Channel의 편집자가 소개 한 내용을 통해 모든 사람이 특정 이해를 가지고 있다고 생각합니다. 더 많은 기술 컨텐츠를 알고 싶다면 未分 새로운 기술 채널에 계속주의를 기울이십시오!