응용 프로그램 계층에 대해 읽고 있는데 다음 프로젝트 (c #, .Net)에서이 디자인을 사용하고 싶습니다. 몇 가지 질문 :
네임 스페이스를 통해 레이어를 분리합니까? Project.BLL. 무엇이든, Project.DAL. 무엇이든
레이어, 컴포넌트 (Project.BLL.Component1) 또는 컴포넌트, 레이어 (Project.Component1.BLL)로 구분하는 것이 더 적합합니까?
내 DAL의 경우이 계층이 다른 클래스를 사용하여 추가로 구성됩니까? 모든 데이터베이스 호출이 단일 클래스에 배치되면 조직이 없습니다. 이것을 다른 클래스 또는 네임 스페이스로 나누는 것이 더 좋습니까?
DAL 클래스는 일반적으로 정적입니까? 매번 메서드 중 하나를 호출하기 전에 DAL 개체를 인스턴스화하는 것은 번거로운 것 같습니다.
이 레이어로 올바른 방식으로 작업을 수행하는 다른 팁을 주시면 감사하겠습니다.
답변:
아닙니다 . 이렇게하면 단위 테스트가 훨씬 어려워집니다. 종속성 주입 을 사용 하여 각 데이터 액세스 클래스 (예 : IDatabaseService)의 생성자에 종속성을 전달 해야합니다 . 그런 다음 데이터 액세스 오브젝트를 다음과 같이 비즈니스 오브젝트로 전달하십시오.
BusinessObject businessObject = 새 비즈니스 개체 (새 데이터 액세스 개체 (새 데이터베이스 서비스 ())); businessObject.PerformOperation ();
각 비즈니스 오브젝트에는 여러 데이터 액세스 오브젝트가 필요할 수 있습니다. GUI 코드는 또한 하나 이상의 비즈니스 객체를 사용합니다. 일부 비즈니스 오브젝트에는 데이터 액세스 오브젝트가 필요하지 않지만 IDatabaseService를 직접 사용해서는 안됩니다.
1 번과 2 번 문제는 Matthew의 답변과 함께하십시오.
데스크톱 응용 프로그램의 DAL을 구성하는 가장 좋은 방법을 알아 내려고 많은 시간을 보냈습니다. 그리고 가장 좋은 방법은 실제로 응용 프로그램의 요구에 달려 있습니다. 내 응용 프로그램 중 하나에서 각 데이터베이스 테이블에 대해 DA 클래스를 사용하여 중앙 (즉, 단일 톤) DataProvider 클래스에 등록하고 CRUD를 처리했습니다. 그런 다음 각 DA 클래스는 모든 테이블 데이터를 RAM에 캐시할지 여부 (성능!) 및 / 또는 다른 컴퓨터에서 실행중인 다른 클라이언트에서 자동 클라이언트 업데이트를 트리거 할 수 있는지 여부를 결정할 수 있습니다 (다중 사용자 생각) 동시성). 등록 인터페이스를 준수하기 만하면 새로운 DAL 클래스를 추가하기가 매우 쉽습니다.
모든 DAL이 이런 종류의 기능을 필요로하는 것은 아니지만, 접근 방식 자체 (예 : 싱글 톤 데이터 공급자 및 정적 등록이있는 간단한 DAL 클래스)는 새 클래스를 추가하기 시작할 때 내 인생이 훨씬 쉬워 졌다는 것을 알게되었습니다.
매우 간단한 응용 프로그램이 아니라면 CRUD를 더 높은 수준의 클래스로 작성하는 것은 권장하지 않습니다. DAL은 데이터 스토리지의 추상화입니다. 향후 MS SQL 대신 MySQL 만 사용하더라도 데이터 스토리지를 변경하기로 결정한 경우 매우 감사하겠습니다. 또한 BLL 개체는 비즈니스 논리 관계에 의해 구성되어야합니다. DAL 개체는 해당 개체가 나타내는 저장소 컨테이너 유형으로 구성됩니다. 차이점은 극적 일 수 있습니다.
마십시오 하지 당신의 DAL 클래스의 정적을합니다. 코딩 속도가 향상되면 테스트 가능성과 유연성면에서 여러 번 잃게됩니다.