モジュール分割の指針MVC

 Webのフレームワークをはじめプログラム設計において、MVCは有名だと思います。ただ、MVCに分ければ設計は完了するわけでもなく、実際は、MVCはモジュール分割の大きな指針に過ぎません。
 実際は、もっと細かく分けて行かなければなりません。オブジェクト指向設計により細分化したコンポーネント(部品)を作り、そして、アスペクト指向でそれらのコンポーネント(部品)を統合していったりなど、はたまた、ドメイン駆動・テスト駆動などにより、よりオブジェクト指向によるモジュールづくりを分類化したり、細分化したりなど。

曖昧なMVC

 MVCは、あくまでも大雑把なモジュール分割で、Modelなどは、データを保持するところなのか、編集するところなのか更にわけていく必要があります。

 そして、Viewにおいても、最近では、DecoratorやViewModelなど、JSのフロントエンドプログラムをはじめとして画面の処理が段々複雑になってきて、View内においてモジュールを分割するのが一般化しています。(ReactはViewのモジュール分割のフレームワークとして役に立ちます。)

 Controllerは、プログラムの処理上、inputとoutputの結節点になるため、ユーザーインターフェースから離れたデータ処理内においても必要とされ、必ずしもアプリケーションの根幹だけにあるものではありません。つまり、Modelの中にも、Viewの中にもControllerは登場します。

  こうみてくると、実際、MVCは指針としてはいいのですが、至る所でマトリョーシカのように、入れ子のようにMVCが現れます。

IoT時代のMVC

 MVCという言葉が出始めた頃や、10年ぐらい前のアプリケーションなら、実行環境は大体固定されていました。 Webで使うだけ、デスクトップで使うだけというように。

 なので、Viewについては、HTMLだけとか、Window/Frame/Formに関することだけ考えていればよかったと思います。

 ただ、時代は代わり、データは1つでも、スマホ、PC、タブレット、その他様々な機器とのやりとりや、SNSやチャットアプリなど外部アプリとのやり取りも一般化してきました。

 もう、MVCのViewは、単一のViewを表すだけでは不十分になっています。つまり、Viewの上の概念として、「ユーザーインターフェース(UI)」をViewの大きな構成要素として考える必要性がでてきているように思います。

 そして、Modelにおいても、Webやスマホなど、プラットフォームに依存したライブラリやデータのもたせ方をするのではなく、純粋にユニバーサルな形で、データを扱う存在でなければなりません。
 たとえば、JavaなどのWebアプリケーションでいえば、Requestオブジェクトをモデルとしてはならず、あくまでも、インターフェースとのやり取りをする媒介オブジェクトとして捉えないといけません。

ユーザーインターフェース(V)の多様化とデータ処理(M)の独立化

 前述したとおり、IoT時代においてはユーザーインターフェースは多様化しています。
 一方で、データはどんなインターフェースを前にしても、核となる部分は、同一であるべきです。インターフェースごとにデータ処理を作成していたのでは、非効率過ぎます。
 
 プログラム設計において、MVCは、それ本来が漠然とした指針であるのですが、さらにIoT時代においては、より幅広い視点でのモジュール分割とモジュールの独立性が求められているように思います。

 プログラムも単純にプロジェクトフォルダの下に「MVC」をつくったら終わりという時代ではなくなってきているように思います。

 Viewの上にUI、そして、独立したModel。これらを設計のなかで明確に意識してモジュールの分割を進めていく必要があるように思います。

最後に(IoTと言語選定)

 プログラム言語選定において、今までは、どのインターフェースでするからこの言語という形になっていたのが、インターフェースは多様化する以上、そちらに必ずしも配慮する必要はなく、データモデルを効率的に高速で処理することを選定基準においてもよいかもしれません。データ処理部分が独立すればするほど、モデルを中心に考えるのもありかもしれません。

 特にビッグデータを扱う現在、わざわざ速度の遅い言語を選ぶ必要はなく、Rust、Go、Juliaなど書きやすいけど、Javaよりも高速に動く言語もでてきています。フロントを気にせず、事業の大切なコアデータをどの言語で扱うのか、改めて考え直してもよい気もします。
 
 特にインターフェースについては、便利なフレームワークも多くあり、コストがかからないのであればなおのこと、コアな部分こそ重要なコーディングの部分かもしれません。(フロントプログラムはそういっても大変ですが)
 また、インターフェースについては今後も様々なものが出てくる以上、ある意味使い捨てで、コストのかからないものを選ぶのがベストかもしれません。(WebならVueのElementUIの様に手軽にUIがつくれてしまうようなライブラリなどが個人的にはよいと思っています。)

 これはあくまでも個人的な感想です。
 

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.