Django에서 여러 모델에 걸쳐 bussiness 논리를 두는 곳

Question

이 질문에 대한 답을 얻기 위해이 게시물을 모두 읽을 필요는 없습니다.이 게시물의 나머지 부분은 질문이 나오는 컨텍스트 일 ​​뿐이지 만 일반적인 질문은 :

장고에 여러 모델에 걸쳐 bussiness 로직을 넣을 곳은 어디입니까 ??

일부 posibilites :

• 일부보기? 모델/형태의
• 저장 방법 (나는 그렇게 생각하지 않습니다, 그것은, 관리자 및 여러 뷰에서 DRY을 일해야한다)? (어떻게?)
• 청소 Methos의를 모델/형태를? (어떻게?)
• 논리를 분할하고 신호를 사용 하시겠습니까? (어떻게?)
• 기타?

는 문맥 :

1. 부서 : : 5 월 : (위험, 금융, IT, ...)
2. 직원 회사의 다른 부서를 참조

   나는이 모델을 가지고 일정 기간 동안 한 부서에만 속한 다음 다른 부서로 변경됩니다.

3. 프로젝트 : 각 부서는 여러 개의 프로젝트를 가질 수 있으며 프로젝트는 여러 개의 출발점에 속할 수 있습니다.
4. 회원 : join_date 및 leave_date 같은 다른 필드를 포함 직원 및 부서 ManyToMany 관계 사이의 중간 테이블, 중요한 필드는 FK 있습니다 : 부서, FK : 직원을
5. 역사 : 알려 회원 및 프로젝트의 중간 테이블에있는 직원 그가 어떤 부서에서 일하기를 원했을 때, 중요한 분야는 다음과 같습니다 : Membership, fk : Project.
6. CurrentProjects : 부서와 현재 작업중인 프로젝트를 연결하는 테이블입니다.

supos 저는 장고 관리자이고 위험 부서 부서에 있으며 위험 요소는 현재 Proyect1과 Project2가 지정되어 있습니다. 나는 "Jhon 스미스"(예를 들어, 부서에서 인라인 양식을 사용하여) 새로운 직원을 추가하고 저장 버튼을 누를 때, 나는 모델의 역사는이 정보로 업데이트됩니다 원하는 :

 
Membership table (only important fields): 

pk Department Employee  join_date leave_date 
20 Risk   Jhon Smith xxxx  xxxx 


History Table (only important fields): 

Membership Project 
20   Project1 
20   project2 

내 말은 때 새를 직원이 새 부서로 지정되면 해당 부서의 실제 프로젝트가 모두 테이블 히스토리의 해당 회원 부서로 지정되어야합니다.

이 논리는 장고에 어디에 놓아야할까요? 이 논리가 배수 모델을 포함 볼 수 있듯이, 일부 posibilities은 다음과 같습니다 어떤 관점에서

• (나는 그렇게 생각 돈, 그것은 관리자 interfase에 다른 곳에서 일해야한다)의 깨끗한 방법
• 회원, 부서 또는 직원 모델/서식?
• 회원, 부서 또는 직원 모델/서식의 저장 방법은 무엇입니까?
• 논리를 분할하고 신호와 같은 것을 사용해야합니까? (몇 가지 예?)
• 기타?
• 나는 everithing을 복잡하게 끝났습니다. =)

고려 사항 : 코드가 프로세스의 어느 시점에서든 값 오류를 생성 할 수 있고 사용자/관리자가 제한되지 않은 형태로이 오류를 볼 수 있으면 좋을 것입니다.

고마워요.

Answer 1

저는 로직이 어디에 있어야하는지에 대해 논평하고 있습니다. 이 모든 것은 모델 논리처럼 들립니다. Django에는 MVC라는 개념이 약간 섞여 있습니다. 그 순수한 데이터 관계가 나는 그것의 모든 모델 논리를 믿을 때. 가능한 한 영향을 미치는 모델에 가깝게 메소드를 배치하고 트리거링 모델에서 가능한 가장 작은 호출을 생성하는 것이 좋습니다.

앱 분리 방지에 관심이 있다면 신호를 사용할 수 있습니다. 모델 A 대신 저장 중에 XYZ를 호출해야한다는 것을 알고 있으면 다른 방법으로 이동합니다. 모델 A는 신호를 방출합니다. XYZ는 신호에 연결될 책임이 있습니다. 완전히 일반적인 프로젝트 앱에서 신호 정의를 만들 수도 있습니다.이 경우 트리거링 또는 수신 모델 모두 서로의 작업에 대해 알지 못합니다. 그것은 단지 그들을 묶는다.

예를 들어, 모델에 after a save과 같은 신호가 내장되어 있습니다. 즉, 저장 트리거를 찾는 경우 맞춤 설정이 필요하지 않습니다. 그러나 하나의 모델 논리의 다양한 지점에서 "이름이 바뀌 었습니다"와 같은 사용자 정의 신호를 내 보내야한다고 말하면 사용자가 직접 내보낼 수 있습니다.

모델링에

import django.dispatch 

name_changed = django.dispatch.Signal(providing_args=["name"]) 

class ModelA: 
    ... 

    def foo: 
     # something happened here 
     name_changed.send(sender=self, name=the_name) 

모델 B, C, D 개인적

from myApp.modelA import name_changed 

name_changed.connect(modelB.handle_name_change, dispatch_uid="my_unique_identifier") 
name_changed.connect(modelC.handle_name_change, dispatch_uid="my_unique_identifier") 
name_changed.connect(modelD.handle_name_change, dispatch_uid="my_unique_identifier") 

I은 ​​일반적인 필요 앱위한 utils.py 모듈을 작성하는 습관이 "제어기 모델 "논리. 그들은 행동이나 조력자와 더 비슷합니다.

Answer 2

아마도 문제는 "기록"테이블에있는 것입니다. Project 테이블에 어떤 정보가 있는지 모르겠습니다. 그러나 모든 프로젝트의 시작 날짜와 종료 날짜가 있으면 기록 테이블이 중복 된 정보를 처리하고 있습니다. 이 경우 직원이 근무한 프로젝트를 알고 싶다면이 직원이 해당 부서에서 근무한 날짜의 분노를 알아야하며 그 다음에 해당 부서의 프로젝트를 찾아야합니다. 이전 기간.

내 요점을 이해하시기 바랍니다. 만약 아니라면, 더 잘 설명 할 수 있도록 말해주십시오.

그러나 문제와 모델을 이해함에 따라 나는 이력 표가 필요 없다고 생각합니다. 정보를 복제합니다 ...

Project 모델에이 정보 (날짜 범위)가있는 경우 여러 테이블에 원하는 정보를 찾는 문제이므로 해결 방법은 관리자에 있어야합니다. ...

희망 하시겠습니까!