MVCS-모델 뷰 컨트롤러 저장소


35

나는 최근에 iOS 개발을 배우기로 결정했으며,이를 위해 iOS 프로그래밍 : The Big Nerd Ranch Guide를 읽고 있습니다. 이 책에서 저자는 MVCS-Model-View-Controller-Store 디자인 패턴을 설명합니다 . 기본 아이디어는 많은 응용 프로그램이 컨트롤러의 요청 논리를 유지하면서 여러 외부 데이터 소스를 사용하기 때문에 저자 대신 매우 지저분해질 수 있다는 것입니다. 모든 요청 로직을 컨트롤러에서 별도의 객체로 옮기도록 제안하십시오.

간단히 말해서 책을 인용

Model-View-Controller-Store는 요청 로직을 별도의 객체에 넣고이 객체를 상점이라고합니다 (그림 28.4). 상점 오브젝트를 사용하면 중복 코드가 최소화되고 데이터를 가져오고 저장하는 코드가 단순화됩니다. 가장 중요한 것은 외부 소스를 다루는 논리를 명확하고 집중된 목표를 가진 깔끔한 수업으로 옮기는 것입니다. 이를 통해 코드를보다 쉽게 ​​이해할 수 있으므로 유지 관리 및 디버그가 쉬워지고 팀의 다른 프로그래머와 공유 할 수 있습니다.

비동기 저장소의 멋진 점은 많은 객체가 요청을 처리하기 위해 많은 작업을 수행하더라도 요청의 흐름과 응답이 컨트롤러의 한 곳에 있다는 것입니다. 이를 통해 쉽게 읽고 수정할 수있는 코드의 이점을 얻을 수 있습니다.

나는이 패턴에 대해 더 알고 싶었고 다른 사람들이 그것에 대해 무엇을 말해야하는지 알고 싶었지만 온라인에서 검색 할 때 찾을 수있는 유일한 참고 문헌은 같은 책에 대한 것일뿐이었습니다 (패턴이 다른 이름으로 알려진 것일까 요?).

나에게 필자의 논리는 의미가있는 것으로 보이며 일반적인 MVC 패턴의 논리적 확장처럼 보이지만 실제로는 실제로 MVC 패턴에 대한 경험이 많지 않기 때문일 수 있습니다. backbone.js 와 함께 사용되는 MVV의 종류 (즉, MVC라고 생각하면 ).

아마도 더 많은 경험을 가진 사람이 내가 누락 된 MVCS 패턴에 명백한 결함 / 문제가 있는지 여부를 밝힐 수 있기를 바랍니다 .


2
ActionScript의 RobotLegs는 MVCS의 "S"를 사용하여 서비스를 의미합니다. 그러나 본질적으로 같은 방식으로 사용됩니다. 적어도 하나의 다른 예가 있습니다.
Amy Blankenship

1
MVC에서 상점은 일반적으로 모델의 일부입니다. 그것을 DAO 부분이라고합니다.
Florian Margaine

@FlorianMargaine은 Controller와 대조적으로 사용하고 있습니다 (이 책에서 암시 된 것 같습니다 ( "MVC에서 요청 로직은 컨트롤러 개체의 책임입니다")? 그리고 자신의 레이어로 옮기는 데 명백한 단점이 있습니까? ?
Jack

답변:


18

MVCS 디자인 패턴의 경우 "스토어"는 스토리지 로직에 의존하는 경향이 있습니다. iOS의 경우 이는 일반적으로 핵심 데이터 구현입니다. Xcode에서 Core Data-backed 템플릿을 생성하면이 디자인 패턴의 "Store"측면이 AppDelegate 클래스에 반영됩니다.

이것을 다음 단계로 끌어 올리기 위해 코어 데이터 스택 설정을 처리하고 스택과 관련된 모든 페치 / 저장을 처리하는 싱글 톤 관리자 클래스를 만드는 경우가 많습니다. 언급 한 인용문에서 알 수 있듯이 다른 뷰 컨트롤러에서 모든 위치에서 호출을 저장 / 가져 오기하는 것과는 달리 이러한 메소드를 호출하는 것뿐만 아니라 필요한 경우 조정하는 것이 매우 쉽습니다.

"Store"패러다임은 Core Data로 제한되지 않습니다. 귀하의 상점은 웹 서비스 일 수 있습니다. 아마도 Facebook, Twitter, Yelp 또는 다른 REST 기반 API와 상호 작용하는 클래스가 있습니다. 이러한 종류의 클래스에도 Manager라는 이름이 있습니다. 그들은 말 그대로 모든 내부 세부 사항을 관리하므로 다른 클래스가 필요한 것을 정확하게 입력하거나 가져올 수 있습니다.

이 디자인 패턴에 명백한 결함이나 문제가 있다면 ... 디자인 패턴과 마찬가지로 가장 눈에 띄는 문제는 패러다임에 지장을주지 않는 방식으로 프로젝트를 설정하는 것입니다. 특히 새로운 디자인 패턴을 사용하면이 작업이 가장 어려운 부분 일 수 있습니다. "Store"로직을 자체 클래스로 분류하면 코드 유지 관리가 훨씬 쉬워진다는 장점이 있습니다.


통찰력을 가져 주셔서 감사합니다. 실제로 핵심 데이터 스택과 웹 API를 처리하는 단일 관리자 클래스가 있다는 점에서 내가 시작한 접근 방식과 비슷합니다.
Jack

안녕하세요 @ jimstone, Store 논리와 관련하여 약간 혼란 스럽습니다. 도와주세요? 내가 5 개의 모델을 가지고 있다고 가정하고, 각각 2 개의 클래스를 가지고 있는데, 하나는 네트워킹과 다른 객체 캐싱 (코어 데이터와 물건)을 유지합니다. 이제 네트워킹 + 캐시 함수 호출을 포함하는 함수를 호출하는 각 모델 또는 각 모델에 대해 모든 네트워킹 + 캐시 함수 호출을 갖는 단일 Store 클래스를 갖는 개별 Store 클래스가 있어야하므로 컨트롤러는 항상 데이터의 단일 파일에 액세스합니다.
유성

18

이 맥락에서 'Store'는 Repository 또는 Service 와 매우 흡사 합니다. 이 경우 이것은 매우 일반적인 패턴입니다. 결함 / 문제는 구현 및 문제 영역에 따라 다릅니다.

일반적으로 책에서 'Store'를 사용하여 비즈니스 로직 레벨 + 애플리케이션의 일부이거나 아닐 수있는 데이터 세트를 처리하는 데이터 검색 로직 레벨을 나타내는 것처럼 들립니다.

예를 들어 트위터 api를 'Store'에 배치하면 해당 논리를 구획화하는 좋은 방법입니다.

추가 생각 에 MVC의 정의를
사용 하면 (스토어)는 실제로 모델의 하위 세트입니다. MVC에 대한 확장인지 또는 데이터 검색 패턴인지에 대한 설명은별로 유용하지 않습니다. 그들은 같은 코드처럼 보입니다.

결론적으로, 당신은 그들이 제안하는 조언을 따르면 괜찮을 것이라고 생각합니다 (전체적으로 보임).


1
제공 한 링크를 통한 읽기 MVC 패턴의 확장으로 사용되는 것을 제외하고는 비슷하게 들립니다.
Jack

5
+1, 리포지토리 패턴 (리포지토리는 일종의 서비스)에 대한 새로운 이름이 나온 것 같습니다.
MattDavey
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.