여러 비즈니스 레이어를 제공하는 하나의 데이터 액세스 레이어? 안 그래?

Question

ERP 시스템의 데이터 액세스 방법이 포함 된 DAL이 하나 (또는 ​​갖게됩니다.) 있습니다.

비즈니스 측면에서이 DAL을 사용할 컨텍스트가 있습니다. 예 : 바코드 응용 프로그램, 사용자 지정 판매 선택 응용 프로그램, 구매 주문 응용 프로그램.

비즈니스 영역에 하나의 DLL을 생성하여 주요 영역으로 나누는 대신, 신뢰할 수있는 방식으로 DAL과 통신하도록하는 것이 좋습니다. 이것은 내 완성 된 애플 리케이션의 팽창을 줄이는 데 도움이됩니다

이것은 첫 번째 질문입니다. 두 번째는 모든 BL이 액세스 할 수 있도록 비즈니스 계층간에 공통적 인 데이터 Acess 객체가 별도의 프로젝트에 있어야합니다.

마지막으로 이러한 데이터 액세스 개체는 DAL로도 사용됩니다. 많은 메서드가 이러한 개체 목록을 비즈니스 계층 또는 직접 프레젠테이션으로 반환하기 때문에 (일반적이지는 않지만 발생할 것입니다). 그들은 DAO가있는 동일한 공통 클래스를 참조해야합니까?

Answer 1

두 번째 질문에 대한 답변이 상당히 명확하다고 생각합니다. DAL에는 자체 프로젝트가 있어야합니다.

첫 번째 사실은 다른 애플리케이션 요구간에 얼마나 많은 공통점이 있는지에 달려 있습니다. 또한 여러 BLL DLL로 튕겨져 비즈니스 논리 유지 관리의 복잡성이 증가 할지도 고려해야합니다.

동일한 UI의 BLL뿐 아니라 DAL에 액세스하는 마지막 항목에 대해주의해야합니다. 즉, 두 가지 모두에 의존 할 수 있습니다. 간단한 메소드를 BLL에 두는 것이 더 좋을 수 있습니다. BLL은 방금 DAL 기능을 호출하고 모든 것을 UI에서 BLL로 이동하여 DAL로 보냅니다.

물론 이러한 모든 사항을 고려하여 어떤 대답이 응용 프로그램과 개발 방법론에 가장 적합한 지 생각해야합니다.

Answer 2

DAO와 BL이 모두 사용할 수있는 도메인 개체를 가질 수 있습니다. 도메인 객체는 매우 어리 석다. 주어진 객체의 표현이어야한다.

예 :

Bl.Get - 직원 -> 돌아 도메인 개체 직원은

BL.Get-직원 방법은이 경우 직원의 도메인 객체로 데이터 마이닝을 변환하는 DAO를 호출 도메인 개체.

Bl.Get-employee >> 전화 DOA.Get-employee. 모든 데이터베이스 작업은 DAO에서 처리해야합니다.

비즈니스 논리가있는 시나리오에서 코드는 다음과 같이 보일 수 있습니다.

Employee Bl.ProcessRecord(EmployeeDomain Employee) 
{ 
    //Do some logic.... 
    //Perhaps interact with other DAO operations 
    //Have some business logic operations ETC 
    Persist your changes to the database 
    Employee = DAO.Save-employee(Employee) 
    return Employee; 
}