ADO.NET 의 장점 을 충분히 발휘 하려 면 ADO.NET 프로 그래 밍 모델 을 전면적 이 고 깊이 이해 해 야 할 뿐만 아니 라 경험 과 기 교 를 신속하게 정리 하 는 것 도 중요 하 다.ADO 는 이미 다년간 의 실천 경험 을 가지 고 있 으 며 ADO.NET 은 이 를 바탕 으로 더욱 풍부 하고 강력 한 도 구 를 제공 했다.그럼 에 도 불구 하고 ADO.NET 의 디자인 목 표 는 삽입 즉시 사용 할 수 있 는 도 구 를 제공 하 는 것 이 아니 라 모든 프로 그래 밍 작업 을 마우스 클릭 만으로 완성 할 수 있 을 정도 로 간소화 하지 않 는 다. ADO.NET 은 데이터 액세스 모델 에서 각종 논리 적 실 체 를 대표 하 는 대상 을 많이 포함 하 는데 그 중에서 특히 연결,사무 라 는 두 대상 이 가장 중요 하 다.연결 의 역할 은 백 엔 드 데이터 베이스 와 통신 하 는 통 로 를 구축 하 는 것 으로 연결 대상 을 만 들 려 면 특정한.NET 데이터 공급 자 를 바탕 으로 해 야 한다.트 랜 잭 션 대상 은 기 존 연결 대상 에서 만 들 수도 있 고,BEGIN 을 명시 적 으로 실행 할 수도 있 습 니 다. TRAN SQL 문 구 를 만 듭 니 다.이론 은 간단 하지만 실제 적 으로 연결,사 무 를 둘 러 싼 불확실 한 요소 가 많 고 전체적인 안정성 과 효율 에 중요 한 영향 을 미친다. 연결 문자열 을 어떻게 저장 하고 연결 문자열 에 포 함 될 수 있 는 민감 한 정보(예 를 들 어 비밀번호)를 보호 합 니까?어떻게 완벽 한 데이터 접근 전략 을 설계 합 니까?안전성(즉,인증,권한 수여)을 고려 할 뿐만 아니 라 성능 과 신축성 에 큰 영향 을 미 치지 않 습 니까?만약 사 무 를 필요 로 한다 면,어떻게 효율적으로 사 무 를 실현 하고 통제 합 니까?자동 사 무 를 사용 합 니까?수 동 사 무 를 사용 합 니까?ADO.NET 을 사용 할 때 이 문제 들 은 모두 자세하게 고려 해 야 한다. 연결 문자열 데이터베이스 연결 은 중요 하고 유한 하 며 비용 이 비 싼 자원 이기 때문에 연결 대상 을 잘 사용 하 는 것 은 모든 응용의 가장 기본 적 인 요구 이다.데이터베이스 연결 을 사용 하 는 요점 은 다음 과 같다. 연결 문자열 을 저장 하려 면 안전 에 주의해 야 합 니 다.연결 을 열 려 면 늦 어야 하고 연결 을 닫 으 려 면 일찍 해 야 합 니 다.연결 문자열 은 데이터베이스 에 접근 하 는 열쇠 입 니 다.연결 문자열 은 방문 할 데 이 터 를 설명 하 는 것 외 에 사용자 가 왜 그 데이터 에 접근 할 수 있 는 지 에 대한 신분증 도 포함 되 어 있다.데이터베이스 작업 을 수행 할 때 사용자 신분 증명 은 데이터 접근 권한 을 확정 하 는 가장 중요 한 요소 이다. 1.1 연결 문자열 저장 현재 하 드 인 코딩 의 연결 문자열 은 응용 코드 에 직접 컴 파일 되 었 기 때문에 가장 좋 은 성능 을 가지 고 있 습 니 다.그러나 하 드 인 코딩 문자열 은 프로그램의 유연성 에 영향 을 주 므 로 연결 문자열 이 바 뀌 면 프로그램 을 다시 컴 파일 해 야 합 니 다. 연결 문자열 을 외부 에 저장 하여 유연성 을 높 였 으 며,대 가 는 외부 문자열 을 방문 하 는 데 추가 비용 을 지불해 야 한 다 는 것 이다.그러나 절대 다수의 상황 에서 이 로 인 한 성능 비용 은 무시 할 수 있 고 진정 으로 걱정 해 야 할 것 은 안전 문제 이다.예 를 들 어 공격 자 는 연결 문자열 을 수정 하고 훔 칠 수 있다.연결 문자열 을 외부 환경 에 저장 하 는 일반적인 경 로 는 설정 파일,UDL 파일,Windows 레 지 스 트 입 니 다. .NET 프레임 워 크 설정 파일 은 일반 텍스트 파일 로 배치 되 어 접근 이 편리 합 니 다.연결 문자열 에 암 호 를 포함 하면 텍스트 형식 이 가장 큰 결함 이 될 것 입 니 다.암 호 는 명문 으로 저장 되 기 때 문 입 니 다.전용 암호 화/복호화 엔진 을 도입 하 는 것 을 고려 할 수 있 지만 이 부분 은 개발 자가 스스로 완성 해 야 합 니 다. UDL 파일 은 OLE 입 니 다. DB 공급 자가 사용 하 는 텍스트 파일,즉 SQL 서버 위탁 관리 공급 자 는 UDL 파일 을 지원 하지 않 습 니 다.UDL 파일 도 앞의 프로필 과 같은 보안 문제 가 있어 전반적 으로 강점 이 많 지 않다. 마지막 으로 윈도 레 지 스 트 는 천연 안전 한 저장 장소 로 사용 할 수 있다.레 지 스 트 는 관건 적 인 정 보 를 저장 하 는 시스템 지식 창고 로 암호 화 기술 을 결합 하면 비교적 높 은 안전성 을 얻 을 수 있다.레 지 스 트 를 사용 하 는 주요 단점 은 배치 가 번 거 롭 고 등록 키 를 만 들 고 레 지 스 트 에서 데 이 터 를 읽 어야 한 다 는 것 이다.비록.NET 프레임 워 크 는 바 텀 Win 32 를 호출 하 는 그룹 을 제공 합 니 다. API 의 패 키 징 클래스 는 암호 화 기능 을 제공 하지 않 습 니 다.aspnet_setreg.exe 도 구 는 HKEY 를 만 드 는 데 사용 할 수 있 습 니 다.LOCAL_MACHINE 의 등록 키 는 사용자 이름과 비밀 번 호 를 저장 합 니 다.예 를 들 어 aspnetsetreg.exe -k "Software\MyData" -u:userID -p:password。이 명령 은 지정 한 사용자 ID 와 비밀 번 호 를 암호 화 합 니 다. 1.2 연결 탱크 원리 연결 풀 은 연결 대상 을 사용 할 때마다 새 대상 을 만 들 지 않도록 버퍼 풀 을 통 해 기 존의 연결 대상 을 다시 사용 할 수 있 습 니 다.연결 탱크 를 사용 한 후에 소량의 연결 대상 만 있 으 면 대량의 클 라 이언 트 의 수 요 를 만족 시 킬 수 있다. 모든 연결 풀 은 하나의 독립 된 연결 문자열 과 트 랜 잭 션 컨 텍스트 와 연 결 됩 니 다.새로운 연결 을 열 때마다 데이터 공급 자 는 지정 한 연결 문자열 을 연결 탱크 의 문자열 과 일치 시 키 려 고 시도 합 니 다.일치 하지 않 으 면 데이터 공급 자 는 새로운 연결 을 만 들 고 연결 풀 에 추가 합 니 다.연결 탱크 가 생 성 된 후 프로 세 스 가 끝나 지 않 으 면 철거 되 지 않 습 니 다.어떤 사람들 은 이런 처리 방식 이 성능 에 영향 을 줄 것 이 라 고 생각한다.그렇지 않 으 면 활동 하지 않 거나 빈 연결 탱크 를 유지 하 는 데 비용 이 얼마 들 지 않 는 다. 연결 풀 을 만 든 후에 시스템 은 연결 대상 을 만 들 고 연결 풀 에 가입 하여 규정된 최소 연결 대상 수량 에 이 를 때 까지 합 니 다.이후 시스템 은 필요 에 따라 연결 대상 을 새로 만 들 고 가입 해 최대 연결 대상 수량 한도액 에 도달 할 것 이다.프로그램 이 연결 대상 을 요청 할 때 사용 할 수 있 는 연결 대상 이 없 으 며,연결 탱크 의 대상 수가 상한 선 에 도달 하면 대기 열 에 넣 어 달라 고 요청 합 니 다.연결 이 풀 리 면 버퍼 풀 에서 즉시 꺼 내 사용 합 니 다. 연결 문자열 을 프로 그래 밍 방식 으로 구성 하 는 것 을 피하 십시오.여러 입력 데 이 터 를 통합 하 는 방식 으로 연결 문자열 을 만 들 면 주입 식 공격 에 틈 탈 수 있 습 니 다.사용자 가 입력 한 데 이 터 를 사용 해 야 한다 면 엄격 한 검증 이 필요 하 다. 1.3 연결 닫 기 연결 을 닫 을 때 연결 대상 은 다시 사용 할 수 있 도록 연결 풀 로 되 돌아 가지 만 실제 데이터베이스 연결 은 철거 되 지 않 았 습 니 다.연결 풀 을 사용 하지 않 으 면 실제 데이터베이스 연결 도 닫 힙 니 다.여기 서 강조해 야 할 점 은 연결 대상 이 사용 한 후에 명시 적 으로 닫 고 연결 풀 에 되 돌려 야 하 며 쓰레기 수집 기 에 의 해 연결 을 풀 지 말 아야 합 니 다.실제로 연결 대상 의 인용 이 유효 범 위 를 넘 어 섰 을 때 연결 이 반드시 닫 히 는 것 은 아니다.쓰레기 수집 기의 기능 은 물리 적 연결 을 대표 하 는.NET 패 키 징 대상 을 철거 하 는 것 이지 만 밑바닥 연결 도 닫 혔 다 는 것 을 의미 하 는 것 은 아니다. Close 나 Dispose 방법 을 사용 하면 연결 을 연결 풀 로 되 돌 릴 수 있 습 니 다.생존 기간 이 끝나 거나 심각 한 오류 가 발생 했 을 때 만 연결 대상 이 연결 풀 에서 삭 제 됩 니 다. 1.4 연결 탱크 와 안전 만약 한 프로그램의 모든 데이터 접근 작업 이 같은 연결 문자열 을 사용한다 면 연결 탱크 의 장점 은 극한 까지 발 휘 될 것 이다.그러나 이것 은 이상 적 인 상황 일 뿐 응용 프로그램의 다른 요구 와 충돌 할 가능성 이 높다.예 를 들 어 하나의 연결 문자열 만 사용 하면 데이터베이스 라 는 차원 에서 안전 제 어 를 실행 하기 어렵다. 다른 한편,모든 사용자 가 자신의 연결 문자열(즉,모든 사용자 에 게 데이터베이스 계 정 을 설정 하 는 것)을 각각 사용 하 게 한다 면 반드시 대량의 작은 연결 탱크 가 나타 나 고 많은 연결 이 재 활용 되 지 않 을 것 이다.관례 에 따 르 면 이런 문제 의 가장 좋 은 해결 방안 은 두 극단 사이 의 적당 한 절충 점 을 찾 는 것 이다.우 리 는 대표 적 인 공용 계 정 을 설정 하고 저장 과정 을 수정 하여 사용자 표 지 를 나타 내 는 매개 변 수 를 받 아들 일 수 있 으 며 저장 과정 은 들 어 오 는 사용자 표지 에 따라 서로 다른 조작 을 수행 할 수 있다.2.사무 모델 분산 식 기업 의 응용 은 사 무 를 떠 날 수 없다.데이터 액세스 코드 에 사무 관리 기능 을 추가 하 는 것 은 주로 두 가지 방식 이 있 는데 그것 이 바로 수 동 방식,자동 방식 이다. 수 동 방식 에서 프로 그 래머 는 모든 설정 을 작성 하고 사무 메커니즘 을 사용 하 는 코드 를 책임 진다.자동(또는 COM+)사 무 는.NET 클래스 에 성명 식 속성 을 추가 하여 실행 중인 대상 의 사무 특성 을 지정 합 니 다.여러 구성 요 소 를 같은 사무 에서 실행 하 는 데 자동 으로 편리 합 니 다.두 가지 사무 방식 은 모두 로 컬 또는 분포 식 사 무 를 지원 하지만 자동 적 인 사무 방식 은 분포 식 사무 처 리 를 크게 간소화 했다. 주의해 야 할 것 은 사 무 는 비용 이 많이 드 는 작업 이기 때문에 사 무 를 사용 하기 전에 반드시 재삼 고려 해 야 한 다 는 것 이다.만약 사 무 를 사용 해 야 한다 면,가능 한 한 업무 의 입 도 를 줄 이 고,데이터 베 이 스 를 잠 그 는 시간 과 잠 금 범 위 를 줄 여야 한다.SQL Server,단일 SQL 문 구 는 사무,SQL 을 명시 적 으로 설명 할 필요 가 없습니다. 서버 는 자동 으로 모든 문 구 를 하나의 독립 된 사무 로 실행 합 니 다.DTC(Distributed)와 관련 될 필요 가 없 기 때문에 수 동 로 컬 트 랜 잭 션 은 항상 다른 트 랜 잭 션 보다 훨씬 빠 릅 니 다. Transaction Coordinator）。 수 동 사무,자동 사 무 는 서로 다른,상호 배척 하 는 기술 로 여 겨 야 한다.단일 데이터베이스 에서 사무 적 인 작업 을 수행 하려 면 수 동 사 무 를 우선 고려 해 야 한다.하나의 사무 가 여러 개의 원 격 데이터 베 이 스 를 뛰 어 넘 거나 하나의 사무 가 여러 개의 자원 관리자(예 를 들 어 하나의 데이터 베이스 와 하나의 MSMQ 자원 관리자)와 관련 될 때 자동 사 무 를 우선 고려 합 니 다.어쨌든 두 가지 사무 모델 을 혼합 운용 하 는 것 은 피해 야 한다.만약 성능 이 특별히 중요 하지 않다 면,하나의 데이터베이스 조작 에 대해 서도 자동 사 무 를 고려 하여 코드 를 더욱 간결 하 게 할 수 있다(그러나 속도 가 약간 느리다). 한 마디 로 하면 데이터베이스 액세스 코드 의 질 을 향상 시 키 려 면 ADO.NET 대상 모델 을 깊이 이해 하고 실제 상황 에 따라 각종 기 교 를 유연 하 게 활용 해 야 한다.ADO.NET 은 공용 API 로 각종 응용―Windows 창 응용,ASP 페이지 든 웹 서비스 든 ADO.NET 을 통 해 데이터 베 이 스 를 방문 할 수 있 습 니 다.그러나 ADO.NET 은 입력 을 받 으 면서 결 과 를 토 해 내 는 블랙박스 가 아니 라 여러 도구 로 구 성 된 공구 상자 다.
