비즈니스 로직 계층 (BLL)은 어떤 용도로 사용됩니까?

데이터베이스 응용 프로그램에 대한 모범 사례를 읽으면서 소위 "비즈니스 로직 계층"을지지하는 사람들이 자주 나타 났으며 프로젝트에서 가장 적합한 지 (작은 개인 프로젝트)를 결정하려고합니다. 내 문제는 BAL이 DAL이 이미 처리 할 수없는 (쿼리 실행 및 결과를 객체에 매핑) 할 수있는 일을 생각할 수 없기 때문에 내 BLL은 아무것도하지 않고 DAL을 호출합니다.

어쩌면 DAL 이해 야 할 일이 정확히 잘못되었을 수도 있습니다. 그러나 데이터베이스 관리 응용 프로그램에서 BLL에는 어떤 종류의 기능이 필요합니까?

소규모 응용 프로그램의 경우 BLL은 일반적으로 DAL에 대한 통과로 시작됩니다. 난 괜찮아 비즈니스 규칙을 "발견"함에 따라 BLL이 바로 여기에 있습니다. 또한 테스트를 작성할 때 BLL에 필요한 많은 것을 발견하게됩니다. 내 개인 앱의 경우 비즈니스 규칙을 구성하며 BLL은 여전히 ​​규칙을 따릅니다. 저에게 BLL은 시간이 지남에 따라 성장하는 것입니다. 프로젝트에서 더 오래 일할수록 BLL이 커집니다.

소규모 프로젝트를 위해 BLL과 DAL을 결합 할 수 있습니까? 헤어 스타일을 바꿀 때마다 DAL 기술을 변경한다는 사실을 제외하고는 클라이언트 코드를 분리하는 것이 좋습니다.

BLL은 데이터베이스의 일부가 아닌 UI의 일부가 아닌 비즈니스 도메인의 일부 (일반적으로)를 처리합니다. 예를 들어, 고객의 연령을 사용하여 특별 시니어 할인을받을 자격이 있는지 확인하십시오. DAL은이 작업을 수행해서는 안되며 단순히 고객 데이터를 검색 한 다음 BLL이 작업을 마친 후에 할인 데이터와 함께 저장해야합니다. DAL은 CRUD에 더 집중해야합니다. 소규모 응용 프로그램에서는 두 가지 문제가 겹칠 수 있습니다.

앤드류,

비즈니스 논리 계층은 도메인 기반 개발을 수행하고 도메인의 핵심 활동에 집중할 때 끝나게됩니다. 프리젠 테이션 레이어 (gui, web) 및 인프라 스트럭처 레이어 (db, 네트워크 연결 등)를 제거하면 은행 계좌에 돈을 입금하는 등 도메인의 일부인 핵심 활동이 있습니다. 이제 비즈니스 계층을 모델링하고 프레젠테이션 및 인프라와 분리 한 경우 웹 또는 모바일 장치와 같은 다른 용도로 쉽게 포팅 할 수 있습니다. 개발에 대해 생각할 수있는 확실한 방법이며, 내가 본 것에서 불행히도 그렇게 심각하게 받아들이지 않았습니다.

Eric Evans-Domain Driven Design을 소개합니다.이 책은 도메인에 대한 개발 노력을 정당화하는 좋은 책입니다. 분명히, 그것은 반쯤은 건전한 읽기이지만, 추진력을 높이고 오늘날의 시스템에서 개발자가 무엇을 잘못하고 있는지에 대한 강한 신념을 가지고 있습니다.

특정 수의 계층 또는 계층을 가지고 있다고 말하는 것은 없습니다. 그것은 모두 프로젝트의 복잡성에 달려 있습니다. 얼간이 디너 또는 레코드 스토어와 같은 많은 MVC 샘플 앱을 살펴보십시오. 프로세싱 로직이 거의없는 애플리케이션의 경우 이치에 맞지 않기 때문에 모두 2 계층을 사용합니다.

그러나 앱이 작더라도 일반적으로 비즈니스 계층 인 세 번째 계층을 통해 프레젠테이션 계층에서 데이터 계층을 추상화하는 것이 좋습니다. 이를 통해 프레젠테이션 레이어 전체가 아닌 한 곳에서 변경할 수 있습니다.

ORM을 Linq에서 SQL로 Entity Framework (또는 nhibernate)로 변경하기로 결정했다고 가정하십시오. 프리젠 테이션은 프리젠 테이션 모델과 밀접한 관련이 있기 때문에 프리젠 테이션 레이어보다 비즈니스 레이어에서 변경하기가 더 쉬울 것입니다.

MVC, 즉 Model View Controller를 이해한다면 유사한 용어로 애플리케이션 아키텍처를 생각할 수 있습니다. 모델은 데이터 계층과 유사하며 프레젠테이션 계층은 뷰, 비즈니스 계층은 컨트롤러입니다.

황량한 행성의 답변을 보완도메인 기반 설계에 대한 :

양파 아키텍처 도 확인하십시오도메인 기반 설계 개념과 매우 일치하는 .

Business Logic "Layer"가 양파의 핵심이며 모든 인프라 계층 (예 : 데이터 액세스 계층)이 외부 종속성 인 방법에 주목하십시오. 이는 모든 외부 인프라 종속성을 조롱하고 도메인 논리를 완전히 테스트 할 수 있어야하기 때문에 많은 테스트에 도움이됩니다.

제 생각에는 Business Logic Layer는 "순수한 개념적 솔루션"이있는 곳입니다. 나머지는 단지 인프라 구현 세부 사항입니다.

그러나 일부 응용 프로그램에는 이러한 종류의 아키텍처가 필요하지 않을 수 있습니다. 모든 응용 프로그램이 데이터 세트 CRUD 작업 인 경우 '순수한 솔루션'은 실제로 비어있을 수 있으며 데이터베이스 편집 프런트 엔드 만 있으면됩니다. 이 경우 DAL 및 UI 계층에만 초점을 두는 것이 좋습니다.

이 질문에 대한 답은 (IMHO)입니다. "DAL을 완전히 교체하고 비즈니스 로직 코드를 다시 작성할 필요가 없습니까?"

프리젠 테이션 레이어와 같이 생각하십시오. 다른 GUI의 GUI 변경을 생각하는 것이 일반적이며, 두꺼운 데스크탑 GUI는 웹 클라이언트로 교체되고 iPhone 앱으로 교체됩니다. BLL / DAL에 대해 이와 같이 생각하는 것은 매우 일반적이지 않습니다. 매우 비슷한 것을 제외하고는 실제로 교환되지 않으므로 (예 : SQLServer DB를 MySQL로 교체 한 경우) DB를 분산 스토리지로 변경해야한다고 생각하는 경우 API를 사용하여 액세스 한 서비스의 경우 레이어가 만나는 위치를 더 명확하게 파악할 수 있습니다.