내가 작업중인 아키텍처에 대한 질문이 있습니다.데이터 액세스 레이어를 서비스 레이어와 별도의 레이어로 만드는 것이 좋습니다.
우리는 백엔드 휴식 서비스, 데이터 계층 (python eve 및 편안한 서비스로 구현 됨) 및 데이터베이스를 보유하고 있습니다. 데이터 (액세스) 계층 자체는 독립적 인 안정적인 API입니다.
백엔드 서비스 응용 프로그램에는 데이터 (액세스) 계층을 호출하는 사용자 지정 파이썬 이브 리포지토리가 있으며 데이터 계층은 데이터베이스에서 호출 한 모든 내용을 쿼리합니다.
별도로 지정해야하는 이유 중 하나는 비즈니스 로직 (백엔드 서비스)에서 데이터 로직 (쿼리 로직)을 분리하고자하기 때문입니다.
비용은 명백합니다. 또 다른 계층, 모든 쿼리에 대한 또 다른 I/O 라운드입니다.
아키텍처 경험이있는 사람이라면 누구나이 별도의 데이터 액세스 레이어가 좋은 연습인지 여부 및 그 이유는 무엇일까요?
문제가되는 아키텍처를 살펴보면 프로젝트의 개발 비용을 정당화 할만큼 충분히 커야합니다. 소규모 프로젝트의 경우이 아키텍처는 과도하게 사용됩니다.
프로젝트가 충분히 크다고 가정하면 예; DAL, BLL 및 응용 프로그램 계층을 분리하는 것이 항상 좋습니다. this 및 this을 참조하십시오.
장점은 각 부분을 제어하고 유지 관리 비용을 줄임으로써 이해를 향상시키는 깨끗한 분리입니다.
반면에 비용은 분명합니다 (다른 계층, 다른 I/O 라운드). 예; 그래서 첫 번째 단락에서 프로젝트의 규모에 대해 논의합니다. 대규모 프로젝트에서는 트레이드 오프입니다. 당신은 다른 하나를 선택하고 있습니다.
대규모 프로젝트의 주요 목표는 유지 보수성 IMO입니다. 그것을 이해하십시오 premature optimization is the root of all evil. 따라서 유지 보수가 용이 한 아키텍처로 시작하십시오. 각 기술은 성능 향상을위한 기본 규칙을 권장합니다. 그것들을 처음에 구현하십시오. 당분간 성능 문제가 있으면 찾아서 수정하십시오. 사실 분리 된 레이어로 인해 병목 현상을 쉽게 발견 할 수 있습니다.
다른 장점이 있습니다. 각 레이어를 개별적으로 단위 테스트 할 수 있습니다. 성능 향상, 기술 이동 등 모든 작업을 독립적으로 수행 할 수 있습니다. 디버깅은 너무 쉬울 것입니다.