RIBs를 이용한 개발 - 1. RIBs란?

저는 Rx를 이용한 MVVM을 기본으로 개발합니다.

이것도 뭐 회사마다 기존에 적용되어 있는 부분이랑 크게 다르지 않도록 하여 주기 때문에 확실한 MVVM이라고 할 수도 없습니다.

MVC로 되어 있는 구조를 나혼자 MVVM으로 바꾸기도 어렵고 전체 시스템을 다 변경하는것은 더 말이 안되기 때문입니다.

그냥 유연하게 개발하여 주는것이 가장 좋은 방법입니다.

 

RIBs는 Uber에서 만든 Architectural Pattern입니다.

MVC패턴의 한계를 극복하고 VIPER의 복잡성을 개선한 패턴이라고 하네요.

RIBs는 Router, Interactor, Builder의 약자입니다.

 

github.com/uber/RIBs

uber/RIBs

 

Uber RIBs의 wiki에 가면 이런게 있습니다.

이 부분들에 대해서 설명해 보려고 합니다.

Router

A Router listens to the Interactor and translates its outputs into attaching and detaching child RIBs. Routers exist for three simple reasons:

• Routers act as Humble Objects that make it easier to test complex Interactor logic without a need to to mock child Interactors or otherwise care about their existence.
• Routers create an additional abstraction layer between a parent Interactor and its child Interactors. This makes synchronous communication between Interactors a tiny bit harder and encourages adoption of reactive communication instead of direct coupling between the RIBs.
• Routers contain simple and repetitive routing logic that would otherwise be implemented by the Interactors. Factoring out this boilerplate code helps to keep the Interactors small and more focused on the core business logic provided by the RIB.

라우터는 Interactor를 수신하고 출력을 자식 RIB 연결 및 분리로 변환하는 역할을 하게 됩니다.

쉽게 말해서 attach, detach하여서 논리적인 트리 구조를 만들어 주게 됩니다.

Interactor

An Interactor contains business logic. This is where you perform Rx subscriptions, make state-altering decisions, decide where to store what data, and decide what other RIBs should be attached as children.

All operations performed by the Interactor must be confined to its lifecycle. We have built tooling to ensure that business logic is only executed when the Interactor is active. This prevents scenarios where Interactors are deactivated, but subscriptions still fire and cause unwanted updates to the business logic or the UI state.

 

비지니스 로직을 포함하고 있으며, 여기에서 Rx를 subscription 하고, State의 변경을 결정, 어떠한 Data를 저장할 위치를 결정, 자식으로 첨부해야하는 다른 RIB를 결정하게 된다고 합니다.

즉, 로직을 수행하고 이것을 가지고 Router로 Routing call 그리고 RIBs의 attach와 detach를 요청하고 Presenter로 Data를 전달하는 역할을 하게 됩니다.

Builder

The Builder’s responsibility is to instantiate all the RIB’s constituent classes as well as the Builders for each of the RIB’s children.

Separating the class creation logic in the Builder adds support for mockability on iOS and makes the rest of the RIB code indifferent to the details of DI implementation. The Builder is the only part of the RIB that should be made aware of the DI system used in the project. By implementing a different Builder, it is possible to reuse the rest of the RIB code in a project using a different DI mechanism.

 

모든 RIB의 구성 클래스와 각 RIB의 하위에 대한 Builder를 인스턴스화 하는 것입니다.

즉, RIBs의 모든 구성 요소를 생성하고 DI를 정의하도록 합니다. Router, Interactor, View, Component를 생성하는 역할을 합니다.

Component

Components are used to manage the RIB dependencies. They assist the Builders with instantiating the other units that compose a RIB. The Components provide access to the external dependencies that are needed to build a RIB as well as own the dependencies created by the RIB itself and control access to them from the other RIBs. The Component of a parent RIB is usually injected into the child RIB's Builder to give the child access to the parent RIB's dependencies.

 

RIB 종속성을 관리하는 데 사용됩니다. 빌더가 RIB를 구성하는 다른 유닛을 인스턴스화 하도록 지원하여 주도록 합니다.

부모 RIB Builder가 Component를 통해서 자식 RIB Builder에 의존성을 주입하게 됩니다.

View (Controller)

Views build and update the UI. This includes instantiating and laying out UI components, handling user interaction, filling UI components with data, and animations. Views are designed to be as “dumb” as possible. They just display information. In general, they do not contain any code that needs to be unit tested.

 

Optional 이어서 RIBs에서는 꼭 포함되지 않아도 됩니다.

View는 UI를 만들고 업데이트하도록 합니다.

Presenter

Presenters are stateless classes that translate business models into view models and vice versa. They can be used to facilitate testing of view model transformations. However, often this translation is so trivial that it doesn’t warrant the creation of a dedicated Presenter class. If the Presenter is omitted, translating the view models becomes a responsibility of a View(Controller) or an Interactor.

 

Optional 이어서 RIBs에서는 꼭 포함되지 않아도 됩니다.

Interactor와 View간의 통신을 담당하고 Business Model을 View Model로 변환하는 역할을 합니다.

상태를 가지고 있지 않은 것이 특징입니다.

Presenter를 생략하게 되면 View model 변환의 책임은 View또는 Interactor가 하게 됩니다.