일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
- 클린 코드
- swift documentation
- clean architecture
- Xcode
- Refactoring
- swiftUI
- 애니메이션
- Human interface guide
- uitableview
- combine
- Observable
- ribs
- HIG
- Clean Code
- tableView
- collectionview
- UICollectionView
- rxswift
- SWIFT
- map
- 리팩토링
- 리펙토링
- 스위프트
- UITextView
- uiscrollview
- MVVM
- Protocol
- 리펙터링
- ios
- RxCocoa
- Today
- Total
목록Architecture (swift) (34)
김종권의 iOS 앱 개발 알아가기
의존관계 잘 변하는 것에서 변하지 않는것으로 의존관계가 되는게 이상적인 형태 잘 변하지 않는 계층인 Domain계층으로 Presentation과 Data 계층이 의존하는 형태 핵심: Actor가 Entity를 확인하는 flow View는 ViewModel의 메소드를 호출 viewModel은 useCase 실행 > useCase는 Repository(DB or Network)에 데이터 요청 Repository에서 cache에 데이터가 있으면 바로 획득, 없으면 memory cache, disk cache로 기록 Respository로 부터 받은 데이터는 completion의 인수로 받을수 있어서 ViewModel이 이 데이터 획득 ViewModel은 자신의 Output 프로퍼티에 emit > 이 프로퍼티를..
소스 코드의 의존성은 안쪽을 향하게끔 설계 안쪽으로 갈수록 잘 변하지 않는 요소들이기 때문 안쪽의 원은 바깥쪽의 원을 모르는 상태 바깥쪽의 원은 어떠한 것도 안쪽의 원에 영향을 주지 않는 구조 아키텍처 설계의 가정: 사용자(Actor)의 요구사항은 변경이 많이 없고 내부적으로 Web이나 DB, UI가 자주 바뀐다고 가정하여 설계 Entity Entity (=Enterprise Business Rules): Actor가 필요로 하는 데이터 모델을 의미 특정 '도메인'에서 사용되는 struct 모델 ex) Actor가 필요로하는 Movie와 MoviesPage에 관한 Entity struct Movie: Equatable, Identifiable { typealias Identifier = String en..
1. DI패턴 (필요한 곳에서 protocol에 선언하는 방법) 2. 테스트 구조를 고려한 DI패턴 Usecase Test를 위한 ViewModel 구조 ViewModel에 Input, Output이 존재하고 특정 Input일때 mock usecase를 동작시켜서 예상되는 Output이 나오는지 확인 ViewModel의 Input, Output 정의 protocol AInput { func viewDidLoad() } protocol AOutput { var calculatedValue: Observable { get } } protocol AViewModel: AInput, AOutput {} DefaultAViewModel 정의 final class DefaultAViewModel: AViewMode..
1. DI패턴 (필요한 곳에서 protocol에 선언하는 방법) 2. 테스트 구조를 고려한 DI패턴 DI 패턴 ADIContainer와 AViewModel이 있고 DIContainer에서 AViewModel를 만들 때, AViewModel에 필요한 값을 정의하는 방법 DIP와 테스트에 용이하기 위하여 protocol을 통해 설계는 2. 테스트 구조를 고려한 DI패턴 참고 1. DI패턴 (필요한 곳에서 protocol에 선언하는 방법)의 목적 DIContainer자체가 구현체가 되는 패턴 파악 DIContainer가 구현체가 되는 '패턴'에 대해서 보며, 이 방법은 의미없다는것을 알고 Usecase위치는 ViewModel에 있어야한다는 것을 깨닫는 목적 테스트시에 DIContainer 구현체를 변경하는 일..
Domain Layer : 영화 검색 결과 성공한 쿼리를 저장하는 Entities, SearchMoviesUseCase, DIP를 위한 프로토콜 Repository Protocol위치가 UseCase에 존재 UseCase에 주입: 비즈니스로직에 필요한 Repository UseCase끼리는 서로 의존 가능 protocol SearchMoviesUseCase { func execute(requestValue: SearchMoviesUseCaseRequestValue, completion: @escaping (Result) -> Void) -> Cancellable? } final class DefaultSearchMoviesUseCase: SearchMoviesUseCase { private let mov..
MVVM 구조 Presentation Layer: View + ViewModel ViewModel은 UI이벤트가 발생하면 '무엇'을 해야하는지 알고, UseCase를 요청 후 View에 업데이트 알림 역할 Domain Layer: UseCase + Model 비즈니스 로직 계층 저장소에 관한 Interface가 포함 다른 프로젝트에서도 재사용 될 수 있도록, 다른 부분에 의존하지 않고 의존을 받는 상태 (Repository): Domain과 Data의 인터페이스 역할 protocol Data Layer: DataStore + Entity Presenter(ViewModel) vs UseCase ViewModel에 비즈니스 로직을 넣는 경우는 잘못된 접근 비즈니스 로직은 UseCase에 존재 ViewMod..
0) 프로젝트 초기 세팅 1) Todo 앱 구조, LoggedOut RIB 2) Todo 앱 구조 LoggedIn RIB 3) Todo 앱 구조 Rx stream 이전까지 구현된 점 * 정리 - child RIB 생성, DI, attach/detach Child RIB 생성 Parent Router에 Builder 프로퍼티 추가 viewless인 경우: (p)ChildDependency에 ChildViewController가 지정되어 있고, ParentComponent에 VC객체 선언과 init생성자 적용하여 이 값을 주입 (viewless하위에 viewful Child들이 생기는 것을 고려하기위함) Child 의존성 정의 ChildDependency, ChildComponent, parentCompon..
MVC with Coordinator 핵심 MVC는 Coordinator의 존재를 모르며, 어느 화면으로 이동하는지 모르는 상태 ViewController에서 routeToLogin과 같이 호출하면 안되도, finishLoad()와 같이 호출 Coordinator를 자유롭게 갈아 끼울수 있는 모듈화 구조 DI는 Coordinator에서 실행 MVC 2개 준비 FirstViewController SecondViewController 코드 Coordinator 적용 Coordinator 추가 import UIKit protocol FirstControllerDelegate: AnyObject { func run() func onAction() } final class Coordinator: FirstCont..