iota client 重構
目錄
- iota client 目前問題
- 重構想法
- 預計效益
iota client 目前問題
- 跨層分工不明確
- 同層分工不明確
- 元件拆解過少
- 狀態難以管理
- mutable data，到處都可以改
- data object 包山包海
- Read 完之後存到不知名的地方
- 不當重用程式
iota client 目前問題
- 跨層分工不明確
- 同層分工不明確
- 元件拆解過少
-
狀態難以管理
- mutable data，到處都可以改
- data object 包山包海
- Read 完之後存到不知名的地方
- 不當重用程式
目前問題 - 分工不明確
- Dependency 複雜
- 雙向依賴流
- 容易改 A 壞 B
- 越來越難擴充
- 不好找 bug 的源頭
- 容易有重複程式碼 / 重複呼叫
目前問題 - 跨層分工不明確
沒有規定在哪邊寫 DB
Xmpp Received
目前困境 - 跨層分工不明確
沒有 Observer，只能使用 $evalAsync 更新
ChatsService(聊天室列表)
service vs controller
目前問題 - 跨層分工不明確
DB
ChatController(聊天室)
controller 跨 DB
而不是由 service call
Service
目前問題 - 同層分工不明確
ChatService(聊天室)
語意模糊，身兼兩份工作：
- 聊天室頁面的 Service
- message 操作處理
目前問題 - 同層分工不明確
ChatsService (聯絡人列表)
FriendsService 語意模糊，身兼兩份工作：
- 聯絡人頁面的 Service
- 拿 ChatRoom
目前問題 - 同層分工不明確
FriendsService (聯絡人列表)
FriendsService vs AvatarService
目前問題 - 分工不明確
- Dependency 複雜
- 雙向依賴流
- 容易改 A 壞 B
- 越來越難擴充
- 不好找 bug 的源頭
- 容易有重複程式碼 / 重複呼叫
重構想法
- 單向的 Dependency
- Observer Pattern
- 持久化資源接視為一個 Repository
重構想法 - 架構部分
File
...
...
...
Page Service
根據 use case
操作 Repository 層
操作 Storage
隱藏去哪拿的細節
只接觸 Service
只接觸 Repository
使用 Observer 向上通知
interface == use case
interface == 要持久化的所有 CRUD
不可向上使用！
UserRepository
RosterRepository
ChatRoomRepository
FileRepository
AvatarRepository
PreferenceRepository
Note: 不要直接改 instance
重構想法 - 架構部分
File
Pref
...
...
...
Service
根據 use case
操作 Repository 層
操作 Storage
隱藏去哪拿的細節
不接觸 Repository
boundary 不會超出 entity 範圍
boundary 只會是 Aggregate
不會超出 entity 範圍
use case == interface
interface == 要持久化的所有 CRUD
照 Entity 區分 Repo
Clean Architecture
File
Pref
...
...
...
Service
根據 use case
操作 Repository 層
操作 Storage
隱藏去哪拿的細節
不接觸 Repository
boundary 不會超出 entity 範圍
boundary 只會是 Aggregate
不會超出 entity 範圍
有些 Aggregate 在 Repo
有些 Aggregate 在 Service
如何區分？
hide chat room (delete file)
in Service both Repository?
set avatar update status
in Repository?
Clean Architecture
File
Pref
...
...
...
Service
根據 use case
操作 Repository 層
操作 Storage
隱藏去哪拿的細節
不接觸 Repository
boundary 不會超出 entity 範圍
boundary 只會是 Aggregate
不會超出 entity 範圍
想成只有一個 Storage
要持久化的東西都經過他
1use case => 多 repo interface
hideChatRoom => showStatus == 0
hideFile => delete local DB/File
缺點：思維的轉換
need update => updateStaus == 0
interface == 要持久化的所有 CRUD
hide chat room (delete file)
in Service both Repository?
set avatar update status
in Repository?
Clean Architecture
File
Pref
...
...
...
Service
根據 use case
操作 Repository 層
操作 Storage
隱藏去哪拿的細節
不接觸 Repository
boundary 不會超出 entity 範圍
boundary 只會是 Aggregate
不會超出 entity 範圍
Notification Service?
Badge Service?
重構想法 - Repository
UserService
架構比較 - 使用者觸發
View
Controller
app.DB / Xmpp
Repository
View
Controller
app.DB / Xmpp
Repository
UserService
ChatService
FriendsService
FileService
AvatarService
ChatService
ChatsService
FriendsService
ChatService
ChatsService
FriendsService
UserRepository
RosterRepository
ChatRoomRepository
FileRepository
AvatarRepository
PreferenceRepository
一種資源定義一種 Repository
Page Service
Page Service
不可向上使用！
Shared
Shared
架構比較 - Server 觸發
View
Controller
Page Service
app.DB / Xmpp
Repository
View
Controller
app.DB / Xmpp
Repository
ChatService
UserService
FriendsService
FileService
AvatarService
ChatService
ChatsService
FriendsService
ChatService
ChatsService
FriendsService
Notify Subscriber
UserRepository
RosterRepository
ChatRoomRepository
FileRepository
AvatarRepository
PreferenceRepository
Page Service
不可向上使用！
Notify Subscriber
Notify Subscriber
Notify Subscriber
Notify Subscriber
一種資源定義一種 Repository
Shared
Shared
目前問題 - 元件拆解不夠
View Logic
desktop muc
需要為每個元件建立 Component
desktop uc
目前問題 - 不當重用函式
目前問題 - Read 完之後存到不知名的地方
預計效益
- 易於插拔 framework
- 單向流
- 減少改 A 壞 B 的狀況
- 高內聚，低耦合
- 增加擴充性
- 高內聚，低耦合 / 重用元件
- 提升效能
- 單向流 / 高內聚，低耦合
結論
討論並建立
更嚴謹的規範依賴流 & 定義各 class 職責
iota client 重構
By Chang Henry
