계정 전자 메일 활성화 디자인 (최대 절전 모드를 염두에두고)

Question

나는 입력 문제가있는 디자인 문제가 있습니다. 다음은 제약 조건입니다.

1. 각 사용자는 계정을 등록 할 때 작동하는 전자 메일 주소가 있어야합니다. 사용자 계정을 등록 할 때 계정 활성화를 위해 반드시 따라야하는 활성화 코드가있는 활성화 이메일을 보내야합니다.
2. 각 사용자 계정은 정확히 한 회사에있는 정확히 한 사무실에만 있습니다.
3. 회사의 첫 번째 등록 사용자는 회사와 하나의 사무실을 만듭니다. 나머지 회사 사용자는 첫 번째 사용자에 의해 초대됩니다.
4. 회사는 상호 작용할 수 있지만 회사의 첫 번째 사용자가 활성화 된 경우 (즉 등록 후 각 활성화 링크를 클릭 한 경우)에만 상호 작용할 수 있습니다.

   alt text http://i43.tinypic.com/2dj5bhh.png

   일부 세부 탈락되어 상기 도면에서 :

여기가 해결 될 수 있는지의 작은 UML 다이어그램이다. 다이어그램에는 클래스와 필드 만 표시됩니다. 필드에 관해서는 어떤 정보를 저장해야 하는지를 개념적으로 보여주기 위해 사용됩니다. 범위를 무시하십시오.

어떤 생각과 질문 :

• 사용자 및 NotActivatedUser은 대부분 동일합니다. 그들은 단일 클래스 또는 분리되어야합니까? 그들이 분리되어 있다면, 어떤 형태의 Hibernate 상속 지속성을 사용할 것입니까?
• 계정이 일정 시간 후에 활성화되지 않으면 계정을 제거해야합니다. 첫 번째 사용자 인 경우 사용자 및 회사를 만든 사용자도이 두 가지를 모두 제거해야합니다. NotActivatedOffice와 NotActivatedCompany도 필요합니까? (데이터베이스의 분리를 위해)

이러한 종류의 솔루션을 어떻게 설계 하시겠습니까? 비 활성 및 활성 엔터티를 데이터베이스에서 분리 된 상태로 유지하는 것이 중요하다고 생각하십니까? 그 이유는 무엇?

Answer 1

사용자 개체의 상태 (활성화/비활성화)를 나타 내기 위해 상속을 사용하지 않습니다. 작곡 (집계)이 훨씬 더 나은 선택입니다.

집계를 사용하면 AbstractUser는 단순히 사용자가됩니다. 활성화 관련 속성을 사용하여 User 클래스를 오염시키는 대신 클래스를 사용하여 Activation을 모델링 할 수 있습니다. 이렇게하면 멋지고 깨끗한 객체 모델을 얻을 수 있습니다.

데이터베이스 수준에서 여전히 Component mapping이라는 동일한 테이블/레코드에 두 개체를 저장할 수 있습니다. 또는 사용자 및 활성화를 별도의 테이블 (별칭 Entity mapping)에 저장할 수도 있습니다.

Hibernate는 두 유형의 매핑을 모두 지원합니다. 대부분 구성의 문제입니다.

사용자 클래스는 다음과 같은 속성이 포함됩니다 :

• givenName과
• 성
• 이메일
• 활성화 (정품 인증 개체에 대한 참조를)

정품 인증 클래스가 포함됩니다 다음 속성 :

• activationCode (문자열)
• sentOn (이메일이 전송 된 경우)
가
• 이 activatedOn (사용자가 활성화 링크를 클릭하여 시스템을 알려줍니다 현재 날짜/시간 설정의 디폴트는 null는, 사용자가 활성화 된 경우

  from Office o 
      left join fetch o.company 
  where 
      o.administrator.activatedOn != null 
  

  이 쿼리는 Y 있다고 가정 : 당신은 적어도 하나의 활성 사용자를 가지고있는 기업을 알고하는 HQL 쿼리를 사용할 수

자신의 계정 때 null이 아닌) Office 클래스에서 '관리자'속성을 정의했습니다. '관리자'는 Office를 만든 사용자에 대한 참조입니다. 데이터베이스에서 'offices'테이블에는 User 레코드에 대한 외래 키가 있습니다.

이러한 방식으로 관계를 모델링하면 사무실 관리자 (예 : 사무실/회사에서 퇴장했거나 해고 당했음)를 변경할 수 있습니다. 모두 귀하의 유스 케이스에 따라 달라집니다 ...

또한 특정 시간 후에 비활성화 된 계정을 정리하는 데 사용되는 Activation 클래스에 sentOn 속성을 추가했습니다 (UML 다이어그램에서 누락되었습니다).

Answer 2

NotActivatedUser와 ActivatedUser를 구분하지 않습니다. 단지 User 테이블이 있고 "활성화 됨"에 대한 열이 있으며 기본값은 0 (활성화되지 않음)입니다.

한 가지; ActivationMethod를 사용하여 활성화 코드를 별도의 테이블로 나눕니다. 이렇게하면 사용자가 전자 메일이 아닌 다른 계정을 활성화 할 수있는 방법을 원하고 User 테이블에서 "activationCode"열을 제거하는 용도로 사용할 경우 향후 확장이 가능합니다.

나는 사무실과 회사에 대해 걱정하지 않을 것이다. 위에 설명 된 사용 계획에 따라 사용자가 자신을 활성화 할 때까지 다른 사람이 사용할 수 없어야합니다 (따라서 사무실과 회사). 하나의 질문; 왜 활성화되지 않은 사용자가 Office 및 Company를 만들 수 있습니까? 왜 그 활동을 활성화 된 사용자로 제한하지 않습니까?

Answer 3

개인적으로 나는 단지 상태 일 뿐이므로 활성화 된 사용자와 활성화되지 않은 사용자에 대해 두 가지 클래스를 작성하지 않을 것입니다. 활성화 전에이 상태가 복잡 해지면 활성화 상태 등을 참조 할 수 있습니다.

사용자에게 "OfficeOwner"플래그가있는 경우 복잡한 논리없이 언제 사무실을 제거해야하는지 알 수 있습니다.

Answer 4

활성화 된 사용자와 활성화되지 않은 사용자에 대해 동일한 테이블을 사용하면 사용자의 상태는 물론 응용 프로그램의 모든 곳에서 사무실과 회사의 상태를 확인해야합니다.

그런 이유로 정품 인증이 수행 될 때 회사를 설립하는 데 필요한 모든 정보가 포함 된 activationrequest 테이블을 사용하게 될 것입니다.