2009-08-09 6 views
3

현재 작업중인 프로젝트에서 asp.NET 프로파일을 사용하여 메일 링리스트에있는 사용자의 정보와 같은 사용자 정보를 저장합니다.왜 asp.NET 프로필이 그렇게 끔찍한 방식으로 설계 되었습니까?

이제 메일 링리스트에있는 모든 사용자의 목록을 얻으려면 asp.NET 프로필 테이블이 간단하기 때문에 데이터베이스 쿼리를 수행 할 수 없습니다. 모르는 사람들을 위해

은 프로파일 테이블은 두 가지 주요 기둥의 '키'열 및 ​​'값'열을 가지고 있으며, 그들은 그렇게로 구성되어 있습니다

키 : 키 1 : dataType와 : 시작 인덱스 : endIndex : key2 : dataType. . 등

값 : 이 SQL을 사용하여 쿼리 거의 불가능하다

value1value2value3 ..., 그래서 특정 속성은 모든 사용자의 목록을로드하는 것입니다있는 사용자를 찾을 수있는 유일한 옵션 그것을 통해 루프.

회원 수가 150,000 명이 넘는 사이트에서는 당연히 매우 느립니다!

프로필이 이렇게 디자인되었거나 동적으로 생성 된 데이터를 처리하는 데 특별한 이유가 있습니까?

답변

3

제공자 모델의 요점은 데이터 소스를 추상화한다는 것입니다. 아이디어는 개발자로서 데이터 저장 방법이나 형식을 알 필요가 없다는 것입니다. 단지 액세스 할 수있는 공통된 메소드 세트 만 있습니다. 즉, 단일 코드 줄을 변경하지 않고 공급자를 바꿀 수 있습니다. 또한 구체적으로 으로 지정하지 않으면 공급자 메소드를 우회하여 데이터 소스에서 직접 데이터에 액세스 (예 : 데이터베이스로 바로 이동) 할 수 있습니다. 즉, 전체 포인트를 무효화합니다.

기본 ASP.NET 프로필 공급자는 간단한 값 형식 (문자열, ints 등) 만 저장할 수 없으므로 실제로 매우이지만 복잡한 개체와 전체 컬렉션을 단일 필드에 저장할 수도 있습니다. 관계형 데이터베이스에서 그렇게 해보십시오! 그러나 이러한 제네릭의 단점은 효율성을 희생한다는 것입니다. 그렇다면 특정 요구가있는 경우 자체 공급자를 구현해야합니다. 예를 들어 SearchableSqlProfileProvider - The Searchable SQL Profile Provider을 참조하십시오.

물론 세 번째 옵션은 프로필 공급자를 사용하지 않는 것입니다. 아무도 당신을 강요하지 않습니다!다른 프레임 워크에서해야 할 것처럼 자신 만의 클래스/데이터베이스를 구현할 수 있습니다.

1

저는 여러 가지 사용자 지정 공급자 (멤버십/사이트 맵/역할 등)를 구현했으며 havent은 실제로 그 종류의 (이름/값 쌍 또는 XML 데이터)를보고 나서 ASP.NET 프로필 공급자를 보았습니다. 확실하지는 않지만 프로파일은 기본 설정으로 사용자 기본 설정/설정이 특정 사용자에게만 필요합니다. 프로필은 사용자 "데이터"에 대해 쿼리 할 수 ​​있다고 생각하지 않습니까?

참고 : 이것은 제가 아는 생각에 기반한 가정입니다. 다른 점에 대해 의견을 말하십시오.

+0

네가 맞아. 프로필 공급자는 많은 양의 데이터로 작성되지 않았습니다. –

+0

예, 동의합니다 저는 회원 ID 속성이있는 별도의 "사용자"클래스를 보유하고 있습니다.이 클래스는 회원 ID GUID와 해당 클래스의 모든 내 프로필 정보를 연결합니다. – Alex

5

프로필 데이터를 저장하는 것이 좋지 않은 데 동의하지만 유스 케이스는 단일 쿼리로 사용자 프로필 데이터를 얻는 것일뿐입니다. 다른 프로필 속성의 수 원하지 않는 경우 각 값을 고유 한 열로 구분하는 사용자 지정 profile provider을 작성할 수 있습니다. 다양한 회원 및 역할 제공 업체를 구현 한 결과이 작업이 너무 복잡 할 것이라고 생각하지 않습니다. 메소드의 수가 너무 크게 보이지 않습니다.

+0

내 "이론":-)을 지원합니다. 실제로 프로필 공급자를 구현한다는 것은 값을 다르게 저장할 수 있음을 의미하지만, 자체 멤버십 공급자가있는 경우 대신 그 값을 사용할 수없는 이유는 무엇입니까? –

+1

@ 마크 - 확실히 동일한 테이블을 재사용 할 수 있지만 멤버 자격 공급자 인터페이스는 임의의 속성에 대한 액세스 권한을 제공하지 않습니다. 일반적으로 ProfileProvider를 생략하고 자신의 프로파일 처리 코드를 굴려 데이터를 여러 다른 테이블 (연락처, 환경 설정 ...)으로 분리하고 현재 (또는 선택한) 사용자를 기반으로 데이터 계층을 사용하여 액세스합니다. . – tvanfosson

관련 문제