설계 DAL 및 BLL - 새로운 다중 계층 응용 프로그램을 설계하는 동안, 나는 내 <strong>DAL</strong> 및 <strong>BLL</strong> 레이어 디자인에 대한 결정을 내리기 어려움에 직면하고있는 관련 테이블

Question

에 대한 단일/다중 데이터 저장소.

마스터 테이블과 1-1 및 1-Many 관계가있는 여러 테이블에 직원 정보가 분산되어 있다고 가정합니다. 몇몇은 다음과 같습니다,

직원 (마스터 테이블)
Employee_Contact_Detail,
Employee_Education,
Employee_Skill,
Employee_Experience DAL 수준에서

을, 나는 GETALL 같은 일반적인 기능을 제공하는 일반 데이터 저장소를 각 테이블에 대해 GetSingle, Add, Edit, Delete를 선택합니다. 이제

, 내 "일반 데이터 저장소"에서 파생 된 내 "직원 데이터 저장소를"디자인이에서 GetEmployeePersonalDetail, GetEmployeeContactDetail, GetEmployeeEducation, AddEmployeePersonalDetail, EditEmployeePersonalDetail 등과 같은 하나의 클래스에 위에 나열된 모든 관련 테이블에 대한 기능을 추가해야합니다 방법은 "일반 데이터 저장소"에 대한 이점이 매우 적습니다. 다른 방법은 각 테이블에 대해 별도의 데이터 저장소를 만들고 (일반 저장소에서 파생시킨 다음) "Employee"에 대한 비즈니스 논리 계층에서 단일 클래스를 만드는 것입니다.

편집

내가 별도의 비즈니스 로직을 작성하는 경우, 내가 대신 "직원"에 대한 "하나의 비즈니스 로직 클래스"의 다음 DAL 수준에서, 옵션 "각 테이블에 대해 별도의 데이터 저장소"에 대한 이동 한 경우 각 데이터 저장소에 해당하는 클래스가 시나리오에서 볼 때 음산한 접근 방식이 될 것인가?

도움 주셔서 대단히 감사합니다.

Answer 1

귀하의 질문에 언급 된 바와 같이, 이것은 제 의견입니다.

문제 : 이미 기본 저장소가있는 경우

, 왜 각 테이블에 대해 특정 저장소를 작성? 다시 말하지만, BLL에서 각 저장소에 대해 별도의 Service 클래스 (언급 한대로 "비즈니스 로직 클래스")를 생성합니다. 이것은 모두 반복되는 작업이며 관리 및 이해하기가 어렵습니다.

제안 :

당신은 (있는 경우)를 사용하고있는 ORM을 언급하지 않은; 그래서 당신의 ORM이 아래의 아키텍처를 구현하는 데 필요한 기능을 제공한다고 가정합니다.
일반 저장소에서 DAL을 닫는 것이 좋습니다. 특정 테이블에 대해 DAL 클래스를 작성하지 마십시오. 모든 서비스 클래스는 기본 CRUD 기능에 대해 일반 DAL을 사용합니다. 모든 확장 기능은 Service 클래스 자체에서 구현되어야합니다.

각 저장소/테이블에 대해 하나의 클래스를 만드는 대신 서비스 클래스에 대해 다시 작업을 반복합니다. 하나의 서비스에서 관련 다중 테이블 (위의 단락을 참조하여 저장소가 문제가되지 않음)을 더 잘 그룹화하십시오.

예를 들어 모든 테이블에 기본 기능을 제공하는 일반 DAL을 만듭니다. 모든 직원 관련 테이블을 포함하는 EmployeeService을 작성하십시오.모든 회계 관련 테이블을 포함하는 AccountService을 작성하십시오. 마찬가지로 모든 로깅 관련 활동에 대해 LogService 하나의 클래스에서 모든 관련 멤버를 얻으면 서비스와 쉽게 상호 작용할 수 있습니다. 이렇게하면 반복 작업이 줄어 듭니다.

내 this 및 this 질문과 그에 대한 대답을 참조하십시오.

귀하의 우려 사항을 이해하시기 바랍니다.

편집 귀하의 코멘트에서 언급 한 바와 같이 1

, 당신이 우리 EF. 그것은 내가 제안한 것을 구현하는 데 필요한 기능을 지원합니다. 티어 역할

예를 겹칠 대신 DAL의 BLL의 확장 된 기능을 구현

; 그렇습니다. 다른 측면도 동일합니다. 각 테이블에 DAL을 쓸 때 실제로 DAL에 Business Logic이 유출됩니다. 비즈니스 로직이 변경되면 의미가없는 DAL을 수정해야합니다.
내 제안에 따르면 레이어가 겹치더라도 관심사는 여전히 구분되어 있습니다. DAL은 CRUD 만 처리합니다. BLL은 데이터베이스 로직을 포함한 모든 로직을 처리합니다.

프로젝트에서 동일한 전략을 사용 했습니까?

예. 이전에 일부 프로젝트에서는 일반 DAL 대신 각 테이블에 대해 별도의 DAL을 작성했습니다. 이로 인해 엄청난 반복 작업이 발생했습니다. 프로젝트가 비교적 적지 만 유지 관리 오버 헤드가 더 많았습니다. 몇 달 전, 나는 위에서 제안한 것을 구현 한 상대적으로 큰 프로젝트로 시작했다. 우리는 지금 우리에게주는 안도감을 볼 수 있습니다.