django 모델 = 비즈니스 로직 + 데이터 액세스? 또는 데이터 액세스 계층을 장고 모델에서 분리해야합니까?

Question

Django에서 제안 된 소프트웨어 아키텍처는 모든 비즈니스 로직과 데이터 액세스를 모델링하는 것입니다.

그러나 일부 동료는 데이터 액세스 계층을 비즈니스 논리 (비즈니스 서비스 계층)와 분리해야한다고 제안했습니다. 데이터 액세스 계층은 다른 데이터 소스가 사용되는 경우 변경 사항을 격리 할 수 ​​있다는 것을 정당화합니다. 그들은 또한 하나 이상의 모델에있을 수있는 비즈니스 로직이 있다고 말합니다.

하지만 별도의 데이터 액세스 및 비즈니스 논리 계층을 사용하여 코딩을 시작할 때 데이터 액세스 계층은 간단합니다 (기본적으로 db 스키마를 정의하는 모델 코드). 많은 가치를 부여하지는 않습니다.

장고 모델로부터 데이터 액세스를 분리하는 데 정말로 가치가 있습니까? 아니면 장고가 ORM과 함께 충분한 데이터 액세스 레이어를 제공합니까?

상당량의 장고 앱을 구현 한 개발자를 찾고 있으며 자신의 의견을 알아 봅니다. 이것은 중소 규모의 웹 응용 프로그램을위한 것입니다.

Answer 1

장고 개발 3 년 후, 나는 다음을 배웠다.

ORM은 액세스 계층입니다. 더 필요한 것은 없습니다.

비즈니스 로직의 50 %가 모델에 포함됩니다. 이 중 일부는 양식에서 반복되거나 증폭됩니다.

비즈니스 로직의 20 %가 양식에 포함됩니다. 예를 들어 모든 데이터 유효성 검사는 양식에 있습니다. 경우에 따라 양식에서 일반 도메인 (모델에서 허용)을 문제, 비즈니스 또는 산업에 특정한 일부 하위 집합으로 좁 힙니다.

비즈니스 로직의 20 %가 응용 프로그램의 다른 모듈에서 종료됩니다. 이 모듈은 모델 및 양식 위에 있지만보기 기능, RESTful 웹 서비스 및 명령 줄 응용 프로그램 아래에 있습니다.

관리 명령 인터페이스를 사용하여 비즈니스 논리의 10 %가 명령 줄 앱에서 종료됩니다. 파일로드, 추출 및 임의의 대량 변경입니다.

뷰 기능과 RESTful 웹 서비스가 거의 아무 것도하지 않는 것이 중요합니다. 그들은 모델, 형식 및 기타 모듈을 가능한 많이 사용합니다. 뷰 기능과 RESTful 웹 서비스는 HTTP 및 다양한 데이터 형식 (JSON, HTML, XML, YAML 등)을 모방하여 처리됩니다.

또 다른 액세스 계층을 발명하려는 시도는 0 값 연습입니다. .

Answer 2

답변은 응용 프로그램의 요구 사항에 따라 다릅니다.

항상 관계형 데이터베이스를 사용하고 특정 ORM과 결합 될 수있는 응용 프로그램의 경우 데이터 액세스와 모델을 분리 할 필요가 없습니다. Django ORM은 데이터 액세스와 모델이 함께 있다고 가정하는 활성 레코드 디자인 패턴을 기반으로합니다. Pro는 단순성이 높고 유연성이 떨어집니다.

데이터 액세스 및 모델 분리는 개발자가 데이터 액세스 계층과 비즈니스 논리를 완전하게 분리하려는 경우에만 필요합니다. 데이터 맵퍼 설계 패턴으로 수행 할 수 있습니다. 일부 ORM은 SQLAlchemy와 같은이 디자인 패턴을 지원합니다. Pro는 유연성이 뛰어나고 복잡성은 더 복잡합니다.

자세한 내용은 Martin Fowler가 저술 한 "Enterprise Application Architecture의 패턴"을 권장합니다.