리포지토리 패턴이있는 .NET 멤버십

Question

팀은 통합 리포지토리 추상화 뒤에 다양한 데이터 소스를 숨길 도메인 모델을 디자인하는 중입니다. 이 접근 방식의 주요 동력 중 하나는 가까운 미래에 이러한 데이터 소스가 중요한 변화를 겪을 가능성이 매우 높기 때문에 비즈니스 로직을 다시 작성하고 싶지는 않습니다. 하나의 데이터 소스는 원래 기본 ASP.Net 멤버쉽 공급자를 사용하여 구현 된 멤버십 데이터베이스입니다. 회원 공급자는 System.Web.Security 네임 스페이스에 묶여 있지만 우리는 도메인 모델 계층이 System.Web (또는 다른 구현/환경 종속성)에 종속되지 않도록 요구하는 디자인 지침을 가지고 있습니다. 이는 다른 환경에서 사용되기 때문입니다. 우리 웹 사이트가 데이터베이스와 직접 통신하기를 원하지도 않습니다.

MembershipProvider 접근 방식을 추상화 된 n 계층 아키텍처와 조정하는 좋은 방법이 무엇인지 고려하고 있습니다. 저의 초기 감정은 도메인 모델과 상호 작용하고 저장소에서 처리하고 유효성/비즈니스 논리를 처리하는 모델에서 개체를 구현하는 "DomainMembershipProvider"를 만들 수 있다는 것입니다. 그런 다음 저장소는 우리의 (아직 결정되지 않은) ORM/데이터 액세스 도구를 사용하여 데이터 액세스를 구현합니다.

이 접근법에 눈부신 구멍이 있습니까? MembershipProvider 클래스와 긴밀히 협력하지 않아서 뭔가 빠져있을 수 있습니다. 또는 앞서 설명한 요구 사항에 더 부합 할 것이라고 생각하는 접근 방식이 있습니까?

미리 감사드립니다.

감사합니다, 자크

Answer 1

질문은 질문을 받았다 이후 6 개월되었습니다 아무도 내가 우리가 결국 선택한 솔루션을 설명하는 거라고 생각 때문에 답변을 제공 할 수 있었던 것으로 보인다.

기본적으로 우리는 MembershipProvider 구현을 사용하지 않기로 결정했습니다. 대신 저장소에 앉아 자체 맞춤 멤버쉽 서비스를 사용합니다. 우리 저장소가 기본적으로 Linq-to-SQL을 통해 내장 SQLMembershipProvider 기능 (최소한 우리가 필요로하는 기능)을 복제 했으므로 기존 aspnet_Membership 데이터베이스를 유지하는 것이 중요했지만 지금은 NHibernate로 전환 중입니다. . 새로운 모델을 사용하기 위해 모든 웹 사이트를 업그레이드 할 때 1 년 정도 후에 회원 데이터베이스를 교체 할 계획입니다.

사용자 지정 멤버 자격 공급자를 사용할 수도 있지만 결국에는 사용자 지정 구현을 사용하는 것이 더 간단하고 일관성 있으며 유지 관리가 더 쉬워졌습니다. 우리는 여전히 사용자가 로그인되었는지 확인하고 사이트의 보안 영역에 액세스하려고 시도한 사용자를 먼저 인증하지 않고 리디렉션하기 위해 기본 제공 양식 인증 기능을 사용하고 있지만 프로필 공급자와 연결된 기능을 재정의했습니다 .

궁극적으로 회원 공급자가 ASP.Net에서 강력하고 사용하기 쉬운 도구이지만 응용 프로그램에서 사용되는 광범위한 접근 방식과 맞지 않는 경우 고려해야 할 가치가 있습니다. 대체 접근법.

Answer 2

흥미로운 점은 최종 솔루션을 게시 해 주셔서 감사합니다. 나는 비슷한 상황이지만, 커스텀 Membershipprovider를 작성하고있다. DB뿐만 아니라 System.Web 네임 스페이스에 대한 액세스가 필요하기 때문에 공급자를 배치 할 위치를 알 수 없습니다. 그것은 관심사 디자인의이 분리를 위반하는 것 같은 것 같습니다.