2017-04-07 4 views
0

ID를 사용하여 생성되는 인증 및 권한 부여가 필요한 MVC 프로젝트에서 작업하고 있습니다. 또한 프로젝트 데이터베이스에는 시스템을 사용해야하는 주요 엔티티가 포함되어 있습니다. 그 상황을 다루는 연습.자신의 데이터베이스와 mvc5 ID의 통합 및 통합

  1. ID ApplicationUser를 내 요구 사항에 맞게 사용자 정의해야합니까?
  2. 내 테이블 (모델)을 만들고 ID 테이블과 통합하면 어떻게 할 지 모르겠다. 또는 기타 솔루션
+0

첫 번째 해결 방법은 분명히 –

+0

입니다. 다른 엔터티와 다른 요구 사항으로 어떻게 할 수 있습니까? 학생과 강사, 학생에게는 월급이 없지만 강사에게는 있습니다. 가장 좋은 방법은 무엇입니까? 고맙습니다. –

+0

상속을 사용할 수 있습니다. https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/inheritance –

답변

1

ID 엔티티를 사용자 정의해야합니다. ID를 생성해야하는 모든 이유가 있습니다. 더 큰 확장 성을 허용해야합니다. 다른 유형의 '사용자'를 가지려면 ApplicationUser에서 상속해야합니다. 중요한 것은 에서 IdentityUser까지입니다. 이렇게하면 핵심 ID 관계 (역할, 클레임, 로그인 등)가 모두 단일 "사용자"테이블에 묶여있는 반면, 해당 테이블을 확장하거나 추가 테이블을 만들어 추가 사용자 데이터를 보관할 수 있습니다. 기본적

public class ApplicationUser : IdentityUser 

public class Student : ApplicationUser 

public class Instructor : ApplicationUser 

,이 상속 TPH 또한 STI (단일 테이블 상속)라고도 (계층 별 테이블)에 의해 구현된다. 즉, 모든 파생 클래스의 모든 속성은 단일 데이터베이스 테이블의 열로 나타납니다. Discriminator 열이 추가되어 저장된 실제 클래스의 이름 (예 : "ApplicationUser", "Student"또는 "Instructor")이 유지됩니다. EF는 쿼리에서 개체 그래프를 작성할 때이 열을 사용하여 올바른 "사용자"유형을 인스턴스화합니다.

이 접근법에는 장단점이 있습니다. 모든 것이 하나의 테이블에 존재하기 때문에 쿼리는 간단하고 빠릅니다. 그러나이 방법을 사용하려면 각 파생 클래스의 모든 속성이 데이터베이스 수준에서 null 허용 이어야합니다. 그 이유는 Instructor에 필수 열이 있으면 Student을 저장할 수 없기 때문입니다. Student에는 해당 요구 사항을 충족 할 수있는 속성이 없기 때문입니다. 뷰 모델을 사용하여 뷰 수준에서 속성이 필요하도록 계속 적용 할 수 있습니다. 데이터베이스의 실제 열은 null이 가능해야합니다.

대체 방법은 TPT (Table Per Type)를 사용하는 것입니다. 이 상속 전략에서는 모든 공통 속성을 가진 기본 클래스 (ApplicationUser)에 대한 테이블이 만들어집니다. 그런 다음 각 discreet 파생 클래스에 대해 해당 클래스에있는 속성 만있는 테이블이 만들어집니다. 외래 키가 기본 클래스의 테이블에 추가되며 EF는 해당 테이블의 공통 데이터를 파생 클래스 테이블의 특정 데이터에 조인하는 데 사용합니다. 이 방법을 사용하면 데이터베이스 수준에서 NOT NULL을 적용 할 수 있지만 모든 데이터를 가져 오기 위해서는 조인이 필요하므로 쿼리 속도가 느려질 수 있습니다.

가 TPT을 구현하려면, 당신은 당신의 파생 클래스에 [Table] 주석을 추가 할 단순히 필요 노트의

[Table("Students")] 
public class Student : ApplicationUser 

[Table("Instructors")] 
public class Instructor : ApplicationUser 

한 마지막 것은 당신이 UserManager을 이용해야하는 방법이다. AccountController을 스캐 폴딩하면 UserManager 컨트롤러 속성이 설정되고 사용자 생성, 사용자 조회, 비밀번호 변경 등의 작업을 수행하는 데 사용됩니다. 실제로는 UserManager<ApplicationUser>의 인스턴스입니다. 일반 유형이므로이 인스턴스는 실제로 UserManager<ApplicationUser>의 인스턴스입니다.Student 또는 Instructor으로 구체적으로 작업해야하는 경우 UserManager<Student>UserManager<Instructor>을 각각 인스턴스화해야합니다. UserManager<ApplicationUser>의 인스턴스는 파생 형식을 ApplicationUser으로 업 캐스팅하므로 사용할 수 없습니다. 예 :

var student = new Student { ... }; 
await UserManager.CreateAsync(student); 

실제로 ApplicationUser이 데이터베이스에 저장됩니다. 학생 관련 데이터는 삭제되고 Discriminator 열 값은 "ApplicationUser"가됩니다.

+0

정말 감사드립니다. 다시 한번 감사드립니다! –

관련 문제