Creative Commons License

Microsoft .NET

닷넷!시작하기
닷넷! Ver 2.0~
닷넷!스킬업
웹개발
윈폼개발
실용모듈개발
Tip & Tech
하루 한 문법

Microsoft .NET 개발자들을 위한 공간입니다. 기초강의에서 부터 고급 기술 정보 및 팁등을 다루도록 하겠습니다.

.

웹개발

이제 웹 기반 응용개발 지식은 거의 필수적으로 요구되는 시대입니다. 구체적인 웹 사이트 개발은 아니더라도 거시적인 웹 기반 서비스에 대한 지식 배양을 위해 할 것이 참 많네요 ^^

[ASP.NET] MemberShip, Role, Profile

작성자 : 박종명
최초 작성일 : 2008-06-25 (수요일)
최종 수정일 : 2008-06-25 (수요일)
조회 수 : 4879

이번 글에서는 ASP.NET 2.0 에서 새로 선보인 MemberShip, Role, Profile 에 대한 간략한 개요와 적용 시 문제점 등을 다룬다.
즉, 상세한 기능 설명이나 적용을 위한 실제 적용코드나 개발적인 부분을 포함하지 않는다.

사이트에 적용하기 위한 몇 가지 걸림돌(?)에 대한 개인적인 의견임을 밝힌다

= MemberShip , Role , Profile =

 

ASP.NET 2.0 에서는 사이트의 회원 인증,권한,정보 관리를 위해 프레임워크 차원에서의 API 와 컨트롤을 제공하게 되었다. 회원제로 운영되는 대부분의 사이트는 회원에 대한 식별(인증), 권한 제어, 추가 회원정보 수집/관리 업무를 필요로 하는데 이런 공통적인 영역에 대한 닷넷의 친절한 지원이라고 볼 수 있다.

 

 

- 회원 관리를 위한 공통 요소 -

 

1. 회원 인증 : 사이트에 등록된 회원이지를 식별한다

2. 회원 권한 : 인증 받은 회원의 컨텐츠 사용에 대한 전체 및 부분별, 등급별 제어(허가) 한다

3. 추가 회원 정보 : ID/PW 와 같은 필수적인 회원 정보 이외에 사이트의 특수 목적을 위해 수집되는

                   추가 회원정보의 관리

 

 

- 상황에 따른 서비스 선택 -

 

1. 회원 가입,수정,탈퇴(블록처리) 및 로그인, 로그인상태처리,비밀번호 찾기,변경과 같은 일반적인 회원관리를 위해서

   는 MemberShip 서비스를 이용하면 된다.

2. 회원 등급제 운영, 권한 설정,권한별 접근 제어와 같은 회원의 권한관리를 위해서는 Role 서비스를 이용하면 된다.

3. 회원의 기본정보(ID,Password,Email) 이외에 추가적인 정보를 관리하기 위해서는 Profile 서비스를 이용하면

   된

 

이러한 공통 요소 이외에도 닷넷 프레임워크에서는 회원가입 폼, 로그인 폼 과 같은 회원 관리를 위한 완성형의 그래픽 컨트롤을 제공한다.

 

일명 로그인 컨트롤 패밀리라고 하는데 VS 의 도구상자에 보면 아래와 같은 컨트롤을 확인할 수 있다.

 

 

위 컨트롤들을 사용하면 개발자는 별도의 코딩 없이 회원관리를 할 수 있다.

물론 컨트롤의 외관 디자인을 좀 더 섬세하게 가꾸고 싶다면 템플릿 형태로 변환해서 Detail 하게 디자인을 입히면

된다.

 

 

 

- 프로바이더 모델 디자인 패턴 (Provider Design Pattern) -

 

MemberShip Role 그리고 Profile 은 모두 프로바이더(Provider) 모델 디자인 패턴으로 설계되었다.

이는 응용프로그램의 확장을 용이하게 하는 강력한 유연성을 제공해 준다. 데이터 저장소(MS SQL or Oralcle, Active Directory ) 별로 공급자(Provider)를 별도로 두고 있으며 공급자의 교체가 용이토록 하였으며 경우에 따라서는 개발자가 직접 공급자를 제공할 수도 있다.  , 확장에 대한 강력한 유연성을 제공하고 있음을 알 수 있다.

 

 

- 무엇을 고민해야 하는가 -

 

우리의 멋진(?) 사이트에 이와 같은 서비스들을 적용하기 위해서는 무엇을 고민해야 하는가?또는 무엇이 걸림돌이 되는가?에 대해 간략히 짚고 넘어가도록 하겠다.

물론 생각하기에 따라서는 아래에 나열된 사안들이 별거 아닐 수 있지만 또 어떤 상황에서는 아주 성가신 걸림돌이 될 수 있다. (MS SQL 을 저장소로 사용함을 기준으로 설명함)

 

 

1. DB 개체들의 접두어

다음은 이들 서비스를 이용하기 위한 DB 개체들이다.


 

 

일단 aspnet_’. 으로 시작하는 테이블 과 프로시저 명이 맘에 들지 않는다.
MS 에서는 닷넷 프레임워크가 생성한 테이블이라는 의미로 접두어로 ‘aspnet’ 을 사용한 것 같은데 상황에 따라서는 대략 난감해 질 수 있다. 한 팀에서만 사용하는 테이블이거나 하나의 웹사이트에서만 사용할 경우에는 문제가 되지 않을 수 있지만 보통 규모가 좀 있는 회사에서는 회원정보는 여러 팀, 여러 프로젝트에 공통적으로 참조되는 중요한 테이블이 된다. 이러한 범용적인 성격의 회원정보 테이블에 ‘aspnet’ 접두어가 사용된다는 회원정보가 ASP.NET 응용프로그램으로 작성된다는 너무 종속적인 이름이 되어 버린다

이는 프로그래머들이 중요하게 생각하는 변수명 정하기와 유사한 선상에서 고민되어 진다.

만일 이 접두어를 변경하거나 제거 할려고 하면 관련 프로시저를 모두 같이 변경해야 한다는 불편함이 있다.

 

 

2. 컬럼 정체성?

아래는 MemberShip 서비스를 위한 Users 테이블이다

 

이 테이블에서 UserID 는 우리가 흔히 생각하는 UserID 가 아니다. 여기서 UserID MS SQL 테이터 타입 중 하나인 uniqueidentifier 타입의 컬럼이다. 즉 내부적으로 고유한 식별번호가 이 컬럼에 저장된다.

‘AD8F170B-7A00-4E94-82E0-79D483B46537’ 와 같은 알 수 없는 문자가 저장되는 것이다.

우리가 흔히 알고 있는 사용자 id UserName 에 저장된다.

 

 

3. DB 스키마 확장

닷넷이 내부적으로 자동 생성한 MemberShip, Role, Profile 을 위한 Table 들에 컬럼을 추가한다거나 제거 할 경우 관련 저장 프로시저도 다 같이 정상적으로 수정해야 한다. 물론 자동 생성된 Table 을 기준으로 역시 자동 생성된 저장 프로시저라 당연한 이치 이지만 그래도 확장에 걸림돌이 되는 것에는 이의가 없다.

물론 회원의 정보확장을 위해 MemberShip 에 컬럼을 추가하는 것이 아니라 Profile 을 사용해야 한다.

그러면 Profile 에서의 걸림돌을 살펴 보자

 

 

4. Profile 의 정보저장 구조

회원의 추가 정보 관리를 위해 MemberShip 관련 테이블을 손대는 것은 결코 추천되지 않는다.

Profile 를 이용하여 추가 정보의 확장을 생각해 볼 수 있다. 그러나 이 Profile 에도 치명적인(?) 걸림돌이 존재하는데 다음과 같은 정보저장 구조가 문제다.

 

 

PropertyName 은 일종의 Key 에 해당하고 PropertyValuesString,PropertValueBinary Value 에 해당한다.

위 예시에서는 Gender(성별) Address(주소)라는 키 값에 해당하는 Value 를 나타낸다.

, 한명의 회원에 대한 여러 속성들은 특정한 규칙에 의해 단 한 개의  Row 에 저장되는 구조이다.

(성별은 String 으로 주소는 XML 형태로 저장하도록 했다)

PropertyNames 컬럼의 Gender:S:0:1:Address:S:1:61:’ 에 대한 해석은 다음과 같다.

4개의 영역이 콜론(:) 으로 구분되어 져 있다. 각 영역은 다음과 같은 규칙에 의해 생성된다

 

프로필 속성 이름 : 값이 저장되는 필드 : PropertyValuesString 에서의 데이터 시작위치 : 데이터 길이

 

이 규칙으로 우리의 데이터를 파싱해 보면,

‘Gender 라는 속성의 값은 S필드(PropertyValuesString) 에 저장되어 있으며 0의 위치에서 시작하여 1의 길이를 가지고 있다라고 해석되어 진다.

 

이는 ASP.NET Profile 개체를 통한 엑세스에는 아무런 문제가 되지 않으나 SQL 쿼리로 직접 조회하거나 통계를 내고 싶을 경우에는 정말 난감해 진다.

물론 SQL Language 라 규칙을 적용해 적절히 파싱 해서 원하는 결과를 볼 수는 있다. 그러나 편리하다고 할 수는 없을 것이다.

 

또한 이러한 구조는 성능상의 문제점도 내포하고 있는데, 한 회원의 모든 속성이 한 컬럼에만 저장되기 때문에 여러 속성 중 단 한 속성만 변경하려 해도 다른 모든 속성이 같이 움직여야 한다는 것이다.

 

닷넷의 Profile 의 장점을 살리면서 이런 데이터 저장 구조를 단점을 피하기 위해서는 어쩔 수 없이 사용자 정의 Provider 를 손수 개발해야 한다.

 

 

- 최고는 없다. 최적만 있을 뿐… -

ASP.NET 2.0에서 새로이 선보이는 MemberShip, Role, Profile 서비스는 분명히 강력한 장점을 제공해 준다.

 

보편적인 회원관리를 위해 개발자의 추가 코드가 필요치 않는 면에서의 극도의 생산성 향상과
Provider Model Pattern 으로 설계된 유연한 확장성 제공과 프레임워크에서 검증된 안정적인 운영 보장 등의 장점은 이들 서비스의 아주 매력적인 포인트 들이다.

 

앞서 살펴 본 몇 가지 걸림돌들은 상황에 따라서는 전혀 문제가 되지 않을 수도 있고 아주 피곤한 문제가 될 수도

있다.

 

그러나 대체로 이 서비스들은 마음에 들 것이다.


현재의 응용환경에 적용하기 위해 별도의 추가 개발이나 확장이 필요할 지라도 처음부터 개발하는 것보다 훨씬

수월할 수 있다.

 

이들 서비스의 적용 유/무를 판단하기 위한 최고의 정답은 있을 수 없다.

단지 최적을 위한 가이드라인만이 존재 할 뿐이다.

 

현재 당신의 프로젝트에 이 들 서비스 적용을 검토 하고 있다면 단순히 좋겠지라는 안이한 생각도 버리길 바라며, 무조건 확장 하기 힘들어라는 생각도 버리길 바란다.

 

서비스를 어디까지 적용할 것이며 어느 부분을 확장해야 하는지에 대한 명확한 기준을 미리 마련해 둔 상태에서 조심스럽게 서비스를 적용시켜야 할 것이다.

이름
비밀번호
홈페이지
YS <- 왼쪽의 문자를 오른쪽 박스에 똑같이 입력해 주세요