Clean architecture and flux
1 like775 views
Introduced clean architecture and flux
Clean architecture and flux
- 2. Clean architecture https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html ● 최근의 소프트웨어 아키텍쳐들 ● 여러 아키텍쳐 사이에는 매우 유사한 점들이 있음 ○ 프레임워크에 대한 비 의존성 ○ 테스트 가능성 ○ UI에 대한 비 의존성 ○ DB에 대한 비 의존성 ○ 다른 어떤한 에이전시에 대한 비 의존성 ● 이런 특징들을 하나의 액션 아이디어로 통합을 하려는 노력
- 3. Clean Architecture 의존성 방향 - 안쪽으로 ● The outer circles are mechanisms. ● The inner circles are policies. Entity와 Use Cases ● Business Rule ● These use cases orchestrate the flow of data to and from the entities Interface Adapter Frameworks and Drivers. Crossing boundaries - DIP
- 4. Clean Architecture in Android https://github.com/googlesamples/android-architecture https://github.com/googlesamples/android-architecture/tree/todo-mvp-clean/ ● 안드로이드 앱에 여러 패턴을 적용하는 구글 주도 프로젝트 ● MVP + Clean Architecture TODO ○ View와 Presenter를 “Contract”로 뽑음 ○ Presenter에서 Use Case호출, 결과를 View에 업데이트 ○ Use Case에서는 Service 혹은 Repository (Entity 영역)에 접근
- 5. Flux 단방향 데이타 흐름 ● From Action to View A Single Dispatcher Stores Views and Controller-Views Actions Dispatcher를 통한 decouple ActionCreators Store에서 View로는 Event https://facebook.github.io/flux/docs/overview.html#content
- 6. Flux - 요상한점 왜 ActionCreator가 WebApi를 사용하지? 1. WebApi 완료후 Action flow를 만들기 위해 2. Store에서 하는 역할을 단순화하기 위해 3. Dispatching Order때문에 - WaitFor
- 7. Flux 와 Angular JS ActionCreator가 DataSoruce 계층인 API를 사용하는것은 여전히 이상하다. Controller-Views가 모든 Event를 Handling하지 말고 EventHandler 스러운 Controller를 따로두는것은 안좋은건가? - Error Handling에 더 좋을것 같음. AngularJS ● Scope을 DI로 해결 ● $rootScope에 dispatch를 할수 있는 기능 탑제 ● UI Component화 하기 용이 https://github.com/poksion/log-me/tree/master/fyac/public/apps