.NET 멤버십 리포지토리 패턴이 있습니다

Question

우리 팀은 통합 리포지토리 추상화 뒤에 다양한 다른 데이터 소스를 숨길 도메인 모델을 설계하는 과정에 있습니다. 이 접근법의 주요 동인 중 하나는 이러한 데이터 소스가 가까운 시일 내에 상당한 변화를 겪을 확률이 매우 높으며 이런 일이 발생할 때 비즈니스 로직을 다시 작성하고 싶지 않습니다. 하나의 데이터 소스는 원래 기본 ASP.NET 멤버십 제공 업체를 사용하여 구현 된 멤버십 데이터베이스입니다. 멤버십 제공 업체는 System.Web.Security 네임 스페이스에 연결되어 있지만 도메인 모델 레이어가 System.Web (또는 기타 구현/환경 종속성)에 의존하지 않아야하는 설계 가이드 라인이 있습니다. 또한 웹 사이트가 데이터베이스와 직접 통신하기를 원하지 않습니다.

나는 추상적 인 n-tier 아키텍처와 회원 가입자 접근 방식을 조정하는 좋은 접근법을 고려하고 있습니다. 나의 초기 느낌은 도메인 모델과 상호 작용하는 "Domainmbershipprovider"를 만들고 리포지토리를 다루고 유효성 검사/비즈니스 로직을 처리하는 모델에서 객체를 구현할 수 있다는 것입니다. 그런 다음 저장소는 (아직 미정) ORM/데이터 액세스 도구를 사용하여 데이터 액세스를 구현합니다.

이 접근법에 눈부신 구멍이 있습니까? 나는 멤버십 전문가 클래스와 긴밀히 협력하지 않았으므로 무언가를 놓칠 수 있습니다. 또는 위에서 설명한 요구 사항에 더 잘 어울릴 것이라고 생각하는 접근법이 있습니까?

당신의 생각과 조언에 미리 감사드립니다.

안부, Zac

Answer 1

질문이 제기 된 지 6 개월이 지났고 아무도 답을 제공 할 수 없었기 때문에 결국 선택한 해결책을 설명 할 것이라고 생각했습니다.

기본적으로, 우리는 멤버십 전문가의 구현을 사용하지 않기로 결정했습니다. 대신 저장소 위에 앉아있는 자체 멤버십 서비스를 사용합니다. 기존 ASPNET_Membership 데이터베이스를 유지하는 것이 중요 했으므로 저장소는 기본적으로 내장 SQLMembershipProvider 기능 (최소한 필요한 측면)을 복제했습니다. . 계획은 모든 웹 사이트가 새 모델을 사용하도록 업그레이드 될 때 1 년 정도 안에 멤버십 데이터베이스를 교체하는 것입니다.

사용자 정의 멤버십 제공 업체를 사용할 수는 있었지만 결국 사용자 정의 구현을 사용하는 것이 더 단순하고 일관성이 있으며 더 관리하기 쉽다는 것이 분명해졌습니다. 우리는 여전히 사용자가 로그인한지 확인하기 위해 내장 양식 인증 기능을 사용하고 있으며 먼저 인증되지 않고 사이트의 보안 영역에 액세스하려는 사용자를 리디렉션하기 위해 여전히 프로필 제공 업체와 관련된 기능을 재정의했습니다. .

궁극적으로, 우리의 감정은 멤버십 제공 업체가 ASP.NET 내에서 강력하고 사용하기 쉬운 도구이지만 응용 프로그램에 사용 된 더 넓은 접근 방식에 맞지 않으면 대체 접근 방식을 고려할 가치가 있다는 것입니다.

Answer 2

흥미 롭습니다. 최종 솔루션을 게시 해 주셔서 감사합니다. 나는 비슷한 상황에 있지만 사용자 정의 멤버십 프로보더를 작성합니다. System.Web 네임 스페이스뿐만 아니라 DB에 액세스해야하기 때문에 제공자를 어디에 두어야하는지 모르겠습니다. 우려 디자인 의이 전체 분리를 위반하는 것은 하나의 클래스 인 것 같습니다.