나는 '구매 주문서'클래스가 있습니다. 단일 구매 주문에 대한 정보가 들어 있습니다. 나는 데이터베이스 메소드를위한 DAO 클래스를 가지고있다.클래스 데이터 책임
구매 주문을로드하고 업데이트하는 방법에 대한 책임은 어디에 있습니까?
PurchaseOrder 클래스에 DAO 클래스를 직접 사용하는 '.update', 'insert', 'delete'및 '.load'메서드가 있거나 PurchaseOrder 클래스가 DAO 메서드를 모르고 POController 이러한 상호 작용을 관리하는 클래스?
사용자는 한 번에 하나의 PurchaseOrder에 대해서만 작업하게됩니다.
감사합니다.
구매 주문서는 지속성에 대한 세부 사항을 모르고 있어야합니다. 이것은 데이터 액세스 레이어의 일종의 포인트입니다, 그것은 개체의 관리를 처리하고 개체 자체가 구매 주문되는에 집중할 수 있습니다.
모의 구매 주문서를 작성하고 시스템이 지속성 문제에 얽히지 않고 처리하는 방법에 대한 논리를 테스트 할 수 있으므로 시스템을 더 쉽게 테스트 할 수 있습니다.
데이터베이스 상호 작용/액세스에서 "비즈니스 로직"(PurchaseOrder)을 확실히 분리합니다. 다른 공급 업체로 이동해야하는 경우 비즈니스 구현을 방해하지 않고 액세스를 변경하는 것이 더 쉬워지고 데이터베이스 액세스 계층에 동작을 추가하는 것을 피하는 것이 더 쉽습니다.
개인적으로, 나는 상호 작용을 관리하는 객체를 만들 것입니다. 이 논리를 PurchaseOrder 클래스 자체에 넣지 말아야하는 강력한 케이스를 만들 수는 없지만,이 컨트롤러 객체를 만들면 느슨하게 결합 된 객체로 이어질 것입니다.
응용 프로그램이 얼마나 오랫동안 존재한다고 생각 하느냐에 달려 있습니다. 우리 회사의 금속 절단 응용 프로그램은 1985 년부터 지속적으로 개발되어 왔으며 컴퓨터 아키텍처의 여러 변경을 통해 이식되었습니다. 우리의 경우에는 인터페이스 아래에 물건을 쑤셔 넣는 경우가 거의 없습니다. 왜냐하면 우리는 5, 10, 15 년의 상태가 될 것 같지 않기 때문입니다.
컨트롤러 클래스를 사용하여 위의 비즈니스 로직 및 UI 수정 레벨을 변경하지 않고 기본 API를 변경할 수 있습니다. 이 수준은 수년간의 작업을 나타내므로 행동을 유지하는 것이 중요합니다.
프로젝트가 유지 보수되는 대부분의 수명을 기억하십시오. 나중에 디자인을 변경하기 쉽도록하는 모든 작업을 수행하면 막대한 시간을 절약 할 수 있습니다.
PurchaseOrder 클래스는 DAO를 모르는 상태 여야합니다. purchaseOrder 클래스는 데이터 그 자체를 나타내며 그 이상은 나타내지 않아야합니다. 컨트롤러 또는 서비스 관리자 또는 DAO를 사용하여 PurchaseOrder 레코드를 지속 /로드하기 위해 호출 할 항목을 사용하십시오. 따라서 설계 유연성을 최대화 할 수 있습니다. 데이터 모델에는 하나의 장소가 있고, PurchaseOrders를 저장/검색하는 방법에 대한 비즈니스 로직 (컨트롤러)을위한 곳과 실제로 저장 한 곳이 있습니다.
여기에 대해 생각해 볼 중요한 사항은 앞으로 할 수있는 일입니다. 어쩌면 데이터베이스를 다른 데이터베이스로 바꾸고 싶습니까? 그렇기 때문에 PO를 나타내는 클래스에서 데이터베이스와의 상호 작용을위한 코드를 분리해야합니다. 그것은 기본적인 책임의 분리입니다. 그리고 나는 당신이 이미 그것을 해왔기를 바랍니다.
이제 질문을 드리겠습니다. PO 클래스와 DAO 클래스 간의 상호 작용을 관리하는 세 번째 클래스 (컨트롤러)를 원하십니까? 제 생각에 그것은 DAO 클래스에 대한 인터페이스를 얼마나 일반적으로 만들 수 있는지에 달려 있다고 생각합니다. DAO 인터페이스가 다른 스토리지 메커니즘을 사용하지만 인터페이스를 변경하지 않고 플러그인 대체품을 작성할 수있을만큼 일반적이라면 PO 클래스가 인터페이스와 상호 작용하도록 할 것입니다. 그렇지 않으면 컨트롤러 클래스를 작성합니다.
다른 생각은 나머지 구조입니다. 어디서 저장/불러 오기가 시작 되었습니까? PO의 많은 조작 (save, load, print, send-to-customer)을한다면, PO 클래스에 기능을 통합하기보다는 이러한 모든 것을 수행하는 컨트롤러를 갖는 것이 합리적 일 것입니다 . PO 클래스를 수정할 필요없이 PO 작업을 추가 할 수 있다는 장점이 있습니다.
나는 PurchaseOrder를 인터페이스로 만들고 모든 DAO 코드를 구현에 넣은 다음 팩토리를 사용하여 간단하게 유지할 것이다.
내 추론 과정을 살펴 보겠습니다 :
클래스 메소드
기본 원칙 : 지속성 클래스 동작이며
당신은의 분리를 필요로하는 클래스의 방법이어야한다, 그래서 당신은 넣어 DAO 클래스에서 데이터베이스를 다루고, 클래스의 메서드를 사용하여 메서드를 구현합니다.
첫 번째 문제 : 다른 DAO 세트를 지원해야하는 경우 공장을 통해 DAO를 만들어야합니다. 두 번째 문제 : 모든 지속성 동작이 구체적으로 클래스 인스턴스와 관련있는 것은 아닙니다. 예를 들어 List 및 Search 메소드는 클래스가 아니라 클래스 목록을 반환하며 인스턴스에 의존하지 않습니다. 그래서 그들은 근본적으로 정적 메서드입니다.
세 번째 문제 :이 클래스에서 상속을 지원하려고합니다. 이와 같이, 지속성 세부 사항은 부모마다 다릅니다. 정적 메서드가 있다면 문제가 될 것입니다.
그래서 당신은
컨트롤러로 이동
기본 원칙 : 지속성 방법은 하나의 클래스에 속하지 않는, 그들은 더 크고, 따라서 그들은
는 우려의 분리가 필요한 구분해야 다시 DAO가 필요합니다. 이것은 유틸리티 클래스이므로 메서드는 모두 기본적으로 입니다.
첫 번째 문제 : 하나 이상의 지속성 방법을 지원하려면 DAO를 만드는 공장이 필요합니다.
두 번째 문제 : 정적 클래스를 사용할 수 없도록 클래스 계층 구조를 지원하려고합니다. 팩토리를 통해 컨트롤러를 생성해야합니다.
세 번째 문제 : 개발자에게 지나치게 복잡한 API를 제공하고 있습니다. 클라이언트 코드의
예 :
PurchaseOrder po;
PurchaseOrderController poc;
poc = PurchaseOrderControllerFactory.Instance.Create();
po = poc.GetPurchaseOrder(42);
// do stuff
poc.SavePurchaseOrder(po);
그때 나는 처음부터 시작합니다. 행동에서
시작
기본 원칙 : 지속성은 동작하지 않습니다. 행동은 지속성보다 큽니다.
시스템에는 구매 주문 하위 시스템이 있습니다. 귀하의 사용자는 높은 수준 (유스 케이스 수준)에서만 그것과 상호 작용할 수 있습니다. 따라서이 메소드는 구매 주문 사용 사례를 구현합니다. 이 메소드는 필요한 경우 DAO를 사용하여 데이터베이스에 액세스하고 필요한 작업을 수행합니다.
간단히 말해서 PurchaseOrder는 기본적으로 데이터를 전달하는 빠른 방법 인 DTO입니다. 그것은 행동을 가져서는 안됩니다.
클라이언트 코드의 예 :
// It could be a factory if needed.
PurchaseOrderSystem pos = new PurchaseOrderSystem();
List<PurchaseOrder> transacted;
transacted = pos.TransactPurchaseOrders(john, 23);
// Show transacted purchase orders or whatever...