Downloaded 26 times
ブラック企業から学ぶMVCモデル
- 1. ブラック企業から学ぶMVCモデル 第47回 情報科学若手の会2014/09/15
- 2. who?? 2 NAME 廣戸 裕大 TWITTER @about_hiroppy SITE about-hiroppy.com
- 3. 注意1 ! ! 今回はwebアプリケーションではない前提の MVCモデルの話をします プラガブルMVCの話はしません あくまで例として自分のイメージでのブラック企業等なので イメージと違ったらすいません＞＜ 3
- 4. 注意2 ! ! 所属団体とか全く関係ないです ! 4
- 5. 流れ 5 ! ! - MVCとはなんなのか - ブラック企業とはなんなのか - ブラック企業を例えにMVCのいい書き方を考察する - まとめ
- 6. MVCとは？ ! ! Model View Controllerの略称 1979年 Smalltalkという言語のGUI設計で用いられた概念 6
- 7. Smalltalk ! ! ゼロックスのパロアルト研究所で作られた オブジェクト指向プログラミング言語 現在はシンコムからVisualWorksという名前で 販売されている 7
- 8.
- 9. ! ! -Multitier Architecture - PresentationDomainSeparation 9
- 10. Multitier Architecture 10 ユーザインタフェース層 アプリケーション層 ドメイン層 インフラストラクチャ層 上位層 ユーザに情報を表示しユーザの入力を解釈する ドメイン層のオブジェクトを協調させて アプリケーションの問題解決を行う ビジネスに関する知識を持たず作業を調整するだけ ビジネスロジックを表現する部分 上位のレイヤを支える一般的な技術的機能を提供する 下位層 下の層は上の層のことを知っていてはいけない！
- 11. PresentationDomainSeparation ! ! Martin Fowler氏が提唱した プレゼンテーションロジックとドメイン(ビジネス)ロジックが 分かれていると理解しやすいから分けよう！ 11
- 12.
- 13. Model ! ! システム中でのビジネスロジックを担当する 問題対象としてのデータとそのデータに対する操作する データの整合性*においての責任を持つ データの整合性: データの変更が中途半端でつじつまが合わなくなってしまっている状況13
- 14. View ! ! プレゼンテーションロジックでModelがもつ 情報の表示や更新を担当 ユーザ入力の取得の管理もする 14
- 15. Controller ! ! プレゼンテーションロジックでの ユーザー操作のインプットを担当する ModelとViewに対して命令を出す 15
- 16. 16 ユーザインタフェース層 アプリケーション層 ドメイン層 View Controller Model プレゼンテーションロジック ビジネスロジック
- 17. Controller View Model 17 1. 入力を通知2.処理を命令する 3.変更されたことを通知 4.表示する情報を取得
- 18. 18 Controller 1.入力を通知2.処理を命令する 3.変更されたことを通知 View Model 4.表示する情報を取得 ModelがViewに通知する仕組み
- 19. Observerパターン ! ! 最初の初期化時,Modelに対して変更があったときに 情報を受け取りたいViewを登録する 変更されたら登録されたすべてのViewに対して通知を行う 19
- 20. MVCモデルとは？ ! ! Model View Controllerの略称 1979年 Smalltalkという言語のGUI設計で用いられた概念 20
- 21.
- 22. ＿人人人人人＿ ＞ Model2＜ ‾ＹＹＹＹＹ‾ 22
- 23. Model 2 ! ! MVC Model2,MVC2とも呼ばれる 1998年 JSP仕様のドラフトで提唱された MVCをWebサービスに適応させたもの 23
- 24. WebBrowser 1. クライアントからのリクエスト(URL) Controller View Model 24 3. 結果を返す2. リクエストを通知 4. 結果を反映させる 5. レスポンス M → V間での関係性を持たない！
- 25. MVCとModel 2の違い ! ! サーバー側からいきなりModelの状態変更が 通知されることはHTTPがステートレスなのでできない よってControllerを経由しないといけないので ModelからViewへの通知ができない 25
- 26. MVCを使うことによるメリット ! ! - 機能別に分かれているのでテストがしやすい - ViewとModelでの並行開発が可能となる - ほかの部分の変更による影響を受けにくい - 相互参照の回避が容易 - 再利用性が高い 26
- 27.
- 28. ブラック企業 … 28 ! ! ブラック企業（ブラックきぎょう）またはブラック会社（ブラックが いしゃ）とは、広義としては暴力団などの反社会的団体との繋がりを 持つなど違法行為を常態化させた会社を指し、狭義には新興産業にお いて若者(わかもの)を大量に採用し、過重労働・違法労働によって使 いつぶし、次々と離職に追い込む成長大企業を指す ! cf. wikipedia ブラック企業
- 29.
- 30. ブラック企業大賞2014 30 ノミネート要努力賞 株式会社 大庄(居酒屋チェーン「日本海庄や」) JＲ西日本 株式会社 ヤマダ電機 株式会社 A-1 Pictures タマホーム株式会社 東京都議会 株式会社リコー 株式会社 秋田書店 学校法人智香寺学園 正智深谷高等学校・ 株式会社 イスト 実行委員会は９月に入って、緊急ノミネートとしてさらに以下の２企業が緊急に追加された。 ! 株式会社 不二ビューティ（たかの友梨ビューティクリニック） 株式会社ゼンショー（すき家） 株式会社ゼンショー（すき家） 大賞 株式会社 ヤマダ電機
- 31.
- 32.
- 33. 目的 ! ! Fat Controllerを避ける 33
- 34. 34 Controller 主人公 社員(家電量販店)
- 35.
- 36.
- 37. ブラック企業系社員 ! ! 社員(Controller)が一番頑張るパターン また、効率ツール(Model)が貧弱であるパターン 37
- 38.
- 39. 社員(Controller) 2. 在庫の存在確認, 在庫を取得して 在庫の数を減らす 在庫状況の更新 etc … 上司(View) ツール(Model) 39 1. 仕事を通知 3. 仕事が終わったことを通知 4. データの取得
- 40. ブラック企業系社員 40 大量の仕事(ユーザからの入力) 仕事の処理をして 更新をする 仕事が終わったことを知らせる
- 41. 41 問題点 1 ControllerがModelの値を操作する処理をするため カプセル化ができていない
- 42. 42 顧客情報を盗む 転売 ⚠ ブラック企業とは関係ありません
- 43. 43 問題点 2 全体の処理は単一ではないのでControllerに書くと 肥大化してしまう
- 44. 44 在庫管理 生産 生産
- 45. 45 問題点 3 手続きがControllerに書かれることでModelの再利用の メリットが減ってしまう
- 46. 46 処理 A,B,C… 処理 A,B
- 47.
- 48.
- 49.
- 50. 当たり前ですが… Modelにビジネスロジックを書く 50 つまり… ブラック企業はもっとツールを自動化するべき(?)
- 51. 一般企業系社員 ! ! 社員(Controller)は通知だけをする 51
- 52. 社員(Controller) 1. 仕事を通知2.仕事が来たことを通知 上司(View) ツール(Model) 52 3. 仕事が終わったことを通知 4. データの取得
- 53. 一般企業系社員 53 仕事(ユーザからの入力) 仕事の処理をして 更新をする 仕事が終わったことを知らせる 仕事の処理を依頼する
- 54.
- 55. 一般企業系社員 55 仕事(ユーザからの入力) 仕事の処理を依頼する 仕事が終わったことを知らせる Controllerがする 必要性はない
- 56. ホワイト企業系社員 ! ! 社員(Controller)は通知だけをするが 仕事(処理)の通知をするだけで終了の通知はしない 56
- 57. 社員(Controller) 1. 仕事を通知2.仕事が来たことを通知 上司(View) ツール(Model) 57 3. 仕事が終わったことを通知 4. データの取得
- 58. ホワイト企業系社員 58 仕事(ユーザからの入力) 仕事が終わったことを 仕事の処理を依頼する 知らせる
- 59. 社員(Controller) 1. 仕事を通知2.仕事が来たことを通知 上司(View) ツール(Model) 59 3. 仕事が終わったことを通知 4. データの取得 ModelがViewに通知する仕組み
- 60. Observerパターン ! ! 最初の初期化時,Modelに対して変更があったときに 情報を受け取りたいViewを登録する 変更されたら登録されたすべてのViewに対して通知を行う 60
- 61. Observerパターン 61 観察者通知者 View Model 事前に登録しておく 自分自身にchangeのメッセージを送る 登録されたViewに対して updateのメッセージを送る dependency
- 62.
- 63. 63 仕事(ユーザからの入力) 仕事の処理を依頼する 仕事が終わったことを通知
- 64. 64 問題点 ! ! 1. 互いに相手の機能を呼び合っている点 2. Modelは相手のことを知ってはいけない
- 65. 問題点1 65 ! ! 互いに相手の機能を呼び合っている点 ! 密結合の状態の場合 一方の変更が他方に影響を及ぼす可能性がある
- 66. 問題点2 66 ! ! Modelは相手のことを知ってはいけない ! ViewやControllerを参照できるような設計はいけない ModelがViewと一対一での対応をしない可能性があるから
- 67.
- 68.
- 69. MVCの本質 ! ! 疎結合 ! ViewかModelで変更が生じても Controllerを置くことにより問題を吸収できる “デザイン”と”ロジック”における分業化 69
- 70. Controllerの肥大化を防ぐ 70 ! ! - Modelの役割を理解する 決してデータの入れ物ではなく入れ物にいれる役割もある - Controllerの処理範囲 Viewの都合に引っ張られる部分を処理する !
- 71.
- 72. ! ! 人それぞれMVCに対しての捉え方が違うと思いま すのでこれが必ず正しいとは限りません！ ! 72
- 73. 参考文献 73 ! ! - Separating User Interface Code http://martinfowler.com/ieeeSoftware/separation.pdf - The Model-View-Controller (MVC) http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf - Model-View-Controller http://www.cue.im.dendai.ac.jp/~masuda/mvc/
- 74.