FOSE話のつづき。11月24日のセッション。
ポスターセッション「Webアプリケーションのクライアントサイド開発におけるソフトウェア設計モデルの適用」について
■ポスター内容(ここまで過激には書いてませんでしたけど、こういうことらしい)
いままで、サーバー側でMVCとかいって、モデルのUML書いていたけど、
SPAの今、それ、時代遅れじゃね?
WebAPIのUML書いてもねえ・・・データよばれるだけだし・・・
それより、クライアントサイドで、AngularとかReactのモデル
分析したほうがよくね?
だから、クライアント側で、UML書いてみるぜ!
■はなしたこと
・そう、時代遅れなんだよねえ~
サーバー側のMVCは、Strutsなどのアクション指向に基づいている。
でもいまは、Angularなんかがそうだけど、クライアント側で、
コンポーネント指向になっている。
時代の流れとして、コンポーネントに基づいたUMLを書かないと
(っていうか設計しないと)です・・・
・でも、アクション指向で作ったUMLをそのままクライアント側に
もってきて、コンポーネントでうまくいくかというと、そうではないんだよね~
アクションは、コンポーネントごとにまとまっているわけではないので・・・
むしろ、コンポーネントごとにモデル化して、それをangularに落とすとか
するほうがいいんじゃないかなあ?
ポスターセッション「Webアプリケーションのクライアントサイド開発におけるソフトウェア設計モデルの適用」について
■ポスター内容(ここまで過激には書いてませんでしたけど、こういうことらしい)
いままで、サーバー側でMVCとかいって、モデルのUML書いていたけど、
SPAの今、それ、時代遅れじゃね?
WebAPIのUML書いてもねえ・・・データよばれるだけだし・・・
それより、クライアントサイドで、AngularとかReactのモデル
分析したほうがよくね?
だから、クライアント側で、UML書いてみるぜ!
■はなしたこと
・そう、時代遅れなんだよねえ~
サーバー側のMVCは、Strutsなどのアクション指向に基づいている。
でもいまは、Angularなんかがそうだけど、クライアント側で、
コンポーネント指向になっている。
時代の流れとして、コンポーネントに基づいたUMLを書かないと
(っていうか設計しないと)です・・・
・でも、アクション指向で作ったUMLをそのままクライアント側に
もってきて、コンポーネントでうまくいくかというと、そうではないんだよね~
アクションは、コンポーネントごとにまとまっているわけではないので・・・
むしろ、コンポーネントごとにモデル化して、それをangularに落とすとか
するほうがいいんじゃないかなあ?