사용 권한에 플래그 열거 형을 사용하면 어떤 단점이 있습니까?

Question

웹 앱에 대한 역할 기반 보안을 구현할 때 권한, 역할, 사용자 및 UserRole에 대한 데이터베이스에 테이블이 있습니다 (즉, 역할에 사용자 할당).

각 역할에는 권한 집합이 있습니다. 사용 권한은 0, 1, 2, 4 등과 같은 값을 갖는 C# 플래그 열거 형으로 정의됩니다.

데이터베이스에서 역할 테이블에는 역할에 대한 결합 된 권한 플래그를 저장하는 int 필드가 있습니다. (이런 식으로 우리는 별도의 Permissions 테이블 (좋든 나쁘지 않습니까?)과 RolePermissions에 대한 일대 다 테이블을 피할 수 있습니다.

코드에서 사용자의 유효 사용 권한을 계산하여 액세스 권한이 있는지 확인합니다. 역할 (들)은 사용자에게 할당됩니다 .NET에서는에 의해 열거 플래그에 논리 연산을 수행 그렇게 꽤 쉽게

이

그래서 제 질문은 다음과 같습니다..

단점은 그 일에 있는가 이 방법 (역할에 부여 된 각 권한에 대해 하나의 레코드가 포함 된 Permission 테이블 및 RolePermission 링크 테이블을 갖는 것과 반대)

Answer 1

세 가지 즉각적인 단점 :

• 플래그에는 사용 가능한 비트 수만큼의 항목 만 포함될 수 있습니다.
• 데이터베이스로부터의 질의는 이제 좀 더 짜증납니다. SQL을 수동으로 사용하는 경우에만 (역할 테이블에 조인하면 멤버십이 훨씬 좋게 결정됩니다).
• 플래그가 아닌 데이터를 볼 때 누군가가 4 번째 비트의 값 1을 기억하고 있을까요?

생활을 편하게하고 별도의 목록으로 이동하십시오. 컬렉션에 할당 된 사용자는 myPermissions.Contains(new Permission("CanEdit"))으로 매우 멋지게 바뀔 수 있습니다. 그런 다음 다양한 변환 루틴을 사용하여 열거 형이나 문자열과 같은 하드 코드 된 값을 myPermissions.Contains("CanEdit") 등의 권한 표현에 변환 할 수 있습니다.

다른 테이블에서 플래그를 선택할 때 성능에 영향을 미치지 않으며 그 반대의 경우도 있습니다. 어떤 종류의 사용법을보고 있는지 전혀 모르겠습니다.

Answer 2

유일한 단점은 권한을 확인하기 위해 더 많은 코드를 작성하게된다는 것입니다. 사용자 역할이있는 별도의 표를 사용하면 매우 쉽게 결정할 수 있습니다.

• 장점 : (?하지만 누가이 시나리오에 대한 관심) 저장 공간을 절약
• 단점 : 코드에 대한 자세한 복잡성.

Answer 3

3 년 전 프로젝트에서 설명한 것처럼 플래그 열거 형을 사용했습니다. 내 고려 사항 :

• 사용법을 단순화하기 위해 레이어를 만들거나 당신은 '새로운 개발자를위한하지 직관적 인 프론트 엔드
• 그것의 지저분한 코드가 될 겁니다. 다른 사람이이 코드를 유지한다면, 그는 전체 아이디어를 놓치고 더 복잡하거나 버그를 일으킬지도 모른다는 것을 알아라.

---

시 :

각 역할은 권한의 집합이 있습니다. 사용 권한은 0, 1, 2, 4 등과 같은 값을 갖는 C# 플래그 열거 형으로 정의됩니다.

NEVER 플래그 열거에 사용되는 0 ...