前回の続き。
大前提として、画面の表示、ユーザーの入力、業務ロジックは分離して実装するのが正しいとする。これはオブジェクト指向では Model / View / Controller と言われる…が、オブジェクト指向云々はおいといたってそれが正しいのはわかりきっちょる。
非オブジェクト指向プログラマーであれば、次のように考えるだろう。
業務ロジックはできる限り RDBMS に SQL 文で処理させる。そうすることで負荷は DB サーバにかかり、ユーザーとの入出力を受け持つ画面系は軽くすることができる。
これはとっても正しいことである。
極端になると、「フロント部分のオブジェクト指向なんちゃら Windows なんちゃら Web なんちゃらなんつーのはよくわからんので、なんでもかんでもストアドプロシージャで実装して、フロントはそれらをキックするだけにする」などと言い出す方もいらっしゃる。
当方は正直あんまし SQL は得意でないので比較にならんのだけれども、そういう手法でいろいろなことをうまく実現できている方々がいらっしゃるのは尊敬に値する。
ただし、当方の少ない経験上では、ソレをやってデスマったり最終的にボツらなかったプロジェクトにお目にかかったことはないんだが (苦笑)。
オブジェクト指向プログラマは、次のように考える。
とにかく各構成要素はシンプルでなければイカン！
だからして、DB のテーブル構造も SQL 文も徹底的にシンプルにする。
そんで、それらを組み合わせて処理する１つ１つのクラスもシンプルにする。
極端になると、シンプルなクラスが大量になり、洪水をおこしてなにがなんだかわからなくなる。
で、フロント側でやる処理が多くなって、DB サーバは遊んでいるのにフロント側の処理がいっこうに終わらず、まったくスケーラビリティがあがらぬ。。。と。
なんとか稼動はするけれど、結局実用にならないシステムを押し付けられてエンドユーザーはがっかり…みたいな。
うむ？なんかどっちもよくないハナシになってしまったではないか (滝汗)。
要はバランスなんスけどね、このへんのことは。
ハナシを戻して、実はオブジェクト指向を入門者にちゃんと説明できていないことが大きな問題なのではないかとワシは小生意気に思うのであった。
と、ここまで書いて飽きてきたので（ぉぃぉぃぉぃ）、また次回。
コメント