데이터베이스 레이어 디자인

Question

내 프로젝트 중 하나에서 디자인 레벨 질문이 있습니다. 저는 REST를 사용하여 객체를 가져와야하는 프로젝트를 진행하고 있습니다. 예를 들어 고객을 가져와 목록에 표시한다고합시다. 고객에 수행 할 수 있습니다

다음 작업은

• 는

그래서 내가 'CustomerManager'라는 이름의 클래스를 포함 생각 고객 삭제 고객

편집 고객 정보

추가 , 다음 방법 포함,

나는 고객 관련 작업을 수행 할 필요가 이제까지의 ViewController에서

, 나는 내가 디자인 수준의 질문을 얻을 때까지,

Customer * manager = [Customer sharedManager]; 
[manager addCustomer:customer]; 

//fetch customer 
[manager customers]; 

//While deleting 
[manager deleteCustomer:customer]; 

모든보고와 잘 작동이처럼 만드는 데 사용, 이유가 있던 중간 관리자. 모든 작업은 Customer Object에서 수행되었으므로 아래와 같이 Customer Class에서 모든 고객 관련 작업을 수행해야합니다.

@interface Customer 

    + (BOOL)addCustomer:(Customer *)customer; 
    + (BOOL)deleteCustomer:(Customer *)customer; 
    + (BOOL)updateCustomer:(Customer *)customer; 
    + (NSArray *)customers; 

    @end 

여기서 문제는 별도의 클래스에서 네트워크 관련 코드는, 내 모든 모델 클래스에서 내 네트워크 관리자의 구체적인 기준이 필요에도 불구하고있다. 혼란 스럽지만 선택할 수있는 하나.

가장 좋은 방법은 무엇입니까?. 이에 대한 자세한 답변을 드리고자합니다.

Answer 1

여기에 정답이 있다고 생각하지 않습니다. 개인적으로 내 웹 서비스가 내 모델과 상호 작용하는 방법에 대해 필자는 앞뒤로갔습니다. 하지만 몇 가지 포인터를 제공 할 수 있습니다 :

1. CustomerManager는 과잉입니다. 고객 모델은 자체 관리를 담당합니다. 내부에 고객 관련 메소드를 배치 할 수 있습니다. 여기에 별도의 개체가 필요하지 않습니다.
2. 필자는 보통 내 모델에 수퍼 클래스를 사용합니다. 예를 들어, 고객 및 다른 모든 모델이 상속하는 ApplicationModel이라는 클래스를 가질 수 있습니다. 이는 모델의 코드를 말끔히 정리할 수있는 좋은 방법입니다. 모델에 네트워크 관련 코드가 있기로 결정한 경우이 슈퍼 클래스에 배치하는 것이 좋습니다. 그렇게하면 웹 서비스가 작동하는 방식을 변경해야 할 경우 코드를 한 곳에서만 변경하면됩니다.
3. 일반적으로 네트워크 관련 코드를 모델과 별도로 유지하는 것이 좋습니다. 네트워킹 논리를 가능한 한 고립시켜야합니다. 네트워크 관련 코드가 변경되기 쉽고 네트워킹 변경 사항이 코드에 미치는 영향을 최소화해야합니다. 예를 들어 보통 API 래퍼로 서비스하는 클래스를 만들고 API 호출을위한 공용 인터페이스를 제공합니다. 이 클래스는 모델과 인터페이스하는 (즉 JSON 사용자 정의 배열을 파싱하고 고객과 상호 작용하여 해당 객체를 데이터베이스에 추가하는) 메소드의 응답을 파싱하는 책임이 있습니다.

Answer 2

나는 그의 첫 번째 지점에서 Michael Frederick과 의견이 다릅니다.

CustomerManager는 고객 모델 객체 자체에 고객 CRUD 작업을 배치하는 것보다 훨씬 좋은 아이디어입니다.첫 번째이자 가장 중요한 이유는 고객 모델 클래스의 단일 책임이 단일 고객을 대표해야한다는 것입니다. 추가 고객 집합을 관리하는 것은 아닙니다 (단일 책임 원칙). DDD 조건에서는 고객 클래스가 entity 일 것으로 기대합니다.

모델 개체 (MVC 패턴에서와 같이)와 도메인 개체간에 큰 차이가 있음에 유의하십시오. 주요한 차이점은 모델 객체의 책임은 일부 데이터의 표현이 포함 된 뷰를 제공하고 도메인 객체의 책임이 표현과 관계없이 도메인 개념의 논리적 인 번역 일뿐만 아니라 그 이상이어야한다는 것입니다.

컨트롤러에서 알 수 있듯이 모델에는 일련의 고객이 있어야합니다. 따라서 CustomerModel에 Customer 객체 집합을 보유하게해야합니다. 컨트롤러의 책임은 요청을 처리하고 요청을 기반으로 모델을 적절하게 조작하여 결과가 응용 프로그램의 상태를 일관되게 파악하도록하는 것입니다. CRUD 운영 자체에 대한 책임이 없으며 책임지지 않아야합니다. 일반적으로 multi-layer design에서는 응용 프로그램 계층 서비스가 해당 작업을 담당하게되므로 인프라 계층 repository (또는 DAO)에 위임 할 수 있습니다. 최소한 내 디자인에, 함께 퍼팅과 같이 보일 것이다 :

모든 CRUD를 요청 및 상태 관리의 나눠,이 UML 다이어그램의 왼쪽에 수행됩니다.

가장 간단한 방법은 모든 것이 몇 줄의 코드에 불과하다는 것입니다. 배열에 대해 모두 동일한 CRUD 연산을 수행한다고 가정 해 봅시다. 배열 요소 자체가 배열을 조작해야합니까? 당연히 아니지. CustomerRepository는 배열이고 NetworkManager는 지속성 (즉 메모리)이며 컨트롤러는 배열을 사용하는 액터이고 CustomersModel은 로컬 사본 또는 하위 집합이며 Customer는 배열 요소입니다.