사용자 권한 관리 디자인[그림 설명]

최근 에 한 프로젝트 에서 디자인 한 사용자 권한 의 디자인 은 여러분 과 함께 토론 하고 공유 하고 싶 습 니 다.디자인 사고방식 은 제 디자인 사고방식 이나 제 가 실현 하고 자 하 는 기능 이 라 고 할 수 있 습 니 다.1.사용자 의 권한 은 캐릭터 를 통 해 제어 되 고 한 사용 자 는 여러 개의 역할 을 가 질 수 있 습 니 다.2.사용자 가 서로 다른 역할 을 가 질 때그 권한 은 여러 캐릭터 가 서로 보완 해 야 합 니 다.3.한 캐릭터 가 여러 모듈 을 가지 고 있 습 니 다.4.사용자 의 프론트 메뉴 는 캐릭터 가 가지 고 있 는 모듈 에 따라 결정 되 고 사용자 가 프론트 에 표시 하 는 조작 메뉴 가 다 릅 니 다.5.페이지 의 기능 단 추 는 모듈 에 포 함 된 기능 에 따라 정 의 됩 니 다.모듈 과 캐릭터 가 가 진 권한 을 통 해 제어 합 니 다.6.특정한 모듈 에 어떤 사용자 가 있 는 지,어떤 캐릭터 에 대응 하 는 지 볼 수 있 고 이에 대해 특수 권한 설정 을 할 수 있 습 니 다.7.한 사용 자 를 대상 으로 특수 설정 을 할 수 있 습 니 다.저 는 제 Project 에서 대체적으로 상기 효과 와 기능 을 얻 었 습 니 다.하지만 실제 과정 에서 부족 한 점 이 발견 됐다.전체 권한 디자인 은 데이터 베 이 스 를 바탕 으로 디자인 되 기 때문에 데이터 의 읽 기 는 데이터 의 양 이 많 을 때(내 가 말 한 데이터 의 양 은 만 이상 으로 계산)성능 에 어느 정도 영향 을 미 칠 수 있다.하지만 일반적으로 수천 명의 사용자 같은 것 은 감당 할 수 있 을 것 같 습 니 다.나 는 뒤에서 부족 한 점 을 설명 할 것 이다.데이터 베이스 디자인 기본 디자인:1.우선,데이터 베 이 스 를 디자인 합 니 다.데이터 뱅 크 의 디자인 은 모두 가 기본 표:사용자 표,역할 표,모듈 표,기능 표,관리자 표 에 익숙 할 것 이 라 고 생각 합 니 다.만약 에 기업 성격 과 관련 되면 수요 에 따라 조직 구성 표,그룹 표 등 다른 보조 표 사용자 도 추가 할 수 있 습 니 다.

 
관리 원

역할.

모듈
(제 모듈 표 는 서브 모듈 의 요 소 를 고려 했 기 때문에 깊이 가 있 습 니 다.아버지 모듈 ID 라 는 두 필드 는 나중에 개 발 했 을 때 사고의 변화 로 인해 IsRoot Module,Function Code 를 사용 하지 않 았 습 니 다.전체 권한 시스템 을 더욱 통용 시 키 기 위해 저 는 이 를 다른 표 로 디자인 했 습 니 다)

기능 표(기능 표 는 모듈 에 대응 하 는 기능:추가,삭제,수정,상세,목록,탐색,내 보 내기,가 져 오기 등)
업무 표:사용자-캐릭터 표 모듈-기능 표 캐릭터-모듈 표
한 사용자 의 여러 캐릭터(1 to n),한 캐릭터 의 여러 모듈(1 to n),한 모듈 의 여러 기능(1 to n)을 실현 하려 면 관련 업무 표를 몇 개 더 해 야 합 니 다.그 전에 보기 로 실현 하 는 것 을 고려 해 야 합 니 다.개인 적 으로 보 기 는 데이터 만 읽 고 데이터 조작 을 하지 않 는 것 이 좋 습 니 다.나중에 증명 하 는 것 은 바람 직 하지 않 습 니 다.여기 서 주의해 야 할 것 은 실제 업무 수행 중 입 니 다.중복 되 는 데이터 입력 을 피해 야 합 니 다.이 표 들 은 모두 간단 하지만 매우 중요 합 니 다.
유저-캐릭터:
캐릭터-모듈:

모듈-기능:

보시 다시 피 표 의 구조 가 매우 간단 하고 필드 도 적 으 며 디자인 도 많 지 않다.연 결 된 필드 ID 를 꺼 내 데이터 액세스 로 사용 합 니 다.
보기:사용자-캐릭터-모듈-기능 보기
 
이상 하 게 생각 하 시 겠 지만,왜 여기에 member 가 나타 나 는 지...롤 은?저 희 는 데이터 시트 에 ID 값 만 입 출금 했 기 때문에 해당 하 는 RoleName 필드 는 포함 되 어 있 지 않 습 니 다.이 보 기 는 관련 표 에 필요 한 다른 필드 데 이 터 를 가 져 오 는 것 입 니 다.다른 두 개의 보 기 는 모두 가 이름 을 보면 그의 용 도 를 알 수 있 을 것 이다.
저장 프로 세 스:각 표 의 추가,삭제,수정 및 목록 데이터.동일 한 데이터 가 있 는 지 판단(CUDLIS-Create,Update,Delete,IfExist,Show,List)
저장 과정 을 일일이 열거 하지 않 겠 습 니 다.아주 간단 합 니 다.아래 의 것들 을 쓰 면 기본적으로 개발 과정 에 많은 문제 가 없 을 것 입 니 다.주의 하 는 것 은 서로 관련 된 업무 표 에서 데이터 삽입 에 대해 중복 데이터 판단(사용자 역할 표,모듈 기능 표,캐릭터 모듈 표,중복 되 는 데이터 삽입 을 최대한 피하 십시오)저 는 대체적으로 실현 해 야 할 업무 열 표를 참고 하 겠 습 니 다.
사용자 표:(삽입,업데이트,IfExist,표시,삭제)
사용자 역할 표:(삽입,업데이트,IfExist,삭제,RoleListByUserID,UserListByRoleID)
캐릭터 시트:(삽입,업데이트,IfExist,표시,삭제)
캐릭터 모듈 시트:(삽입,IfExist,삭제,표시,RoleListByModuleID,ModulistByRoleID)
모듈 표:(삽입,업데이트,IfExist,표시,Dlete,ListByRootModuleID,ListByModuleLevel)
모듈 기능 표:(삽입,업데이트,삭제,FunctionListByModuleID)
사용자 에 게 모든 권한 을 직접 가 져 올 때 보기 에서 MemberRole_Module_Function 에서 해당 하 는 데 이 터 를 얻 으 면 원 하 는 것 을 얻 을 수 있 습 니 다.
데이터베이스 디자인 부분 은 이렇게 차이 가 많 지 않 을 것 이다.나 는 이것 이 통용 되 어야 한다 고 생각한다.실제 운용 과정 에서 저 는 개인 적 으로 개선 점 이 있어 야 한다 고 생각 합 니 다.
1.모듈 과 기능 부분 은 문자열 형식 으로 모듈 에 대응 하 는 기능 을 데이터 필드 에 저장 할 수 있 습 니 다.그러면 코드 작성 에서 많은 시간 을 절약 하고 더 많은 편 의 를 가 져 올 수 있 습 니 다.
2.N 급 모듈 의 권한 에 대해 문 제 를 보 여 줍 니 다.부모 모듈 이 서브 모듈 의 권한 을 어떻게 계승 하 는 지 는 제 가 고려 하지 않 았 습 니 다.하지만 IsRoot Module 이라는 필드 로 글 을 쓸 수 있 을 것 이 라 고 생각 합 니 다.안 타 깝 게 도 이 필드 를 어떻게 정리 해 야 할 지 생각 하지 못 했 습 니 다.서브 모듈 이 많 을 때 프론트 UI 에서 보 여줄 때 느 린 상황 이 발생 하지 않 습 니까?이거 테스트 안 했 어 요.어느 정도 위험 이 있 지만 전단 UI 에서 제 가 아직 생각 하지 못 했 거나 실현 할 수 있 는 방법 을 보 여 주 었 습 니 다.제 가 생각 할 수 있 는 것 은 GridView Tree 처럼 좋 은 것 같 습 니 다.
이 권한 설 계 는 이미 나의 Project 에서 운용 되 었 고 잠시 아무런 문제 도 발견 하지 못 했 으 며 앞으로 다른 시스템 통합 에 도 도움 이 될 것 입 니 다.C\#에서 어떻게 업 무 를 실현 하 는 지 에 대해 개인 적 으로 데이터 베 이 스 를 어떻게 정리 하 는 지 알 면 C\#에서 의 업무 실현 은 취 수 작업 과정 일 뿐 이 라 고 생각 합 니 다.다음 편 은 여러분 과 다시 함께 토론 을 나 누 겠 습 니 다.