考えがまとまってないのですが重要だと思うことについて殴り書きます。
忘れてしまわないようにメモみたいな記事です。
課題意識
ウェブアプリケーションの場合、最終的に画面にデータを表示します。
そのためには
データを取得 -> データの加工 -> データの表示
というプロセスを経ます。
もう少し細かくかくと、例えばAngularなどでは以下のようなプロセスを経ます
DB定義 -> クエリ -> Model -> Modelに対する処理 -> Controller -> Angularのモデル定義 -> AngularのService -> データ処理 -> コンポーネント -> Template
と長い経路を渡ります。
どの部分でどのようなデータ処理をするかを考えることがアプリケーション開発を考える上で肝となる部分です。
このデータ処理のロジックをどこに持つかの考え方に指針を提示する事は、開発効率を大幅に改善するきっかけになると思いました。なので、その事について思ったことを書いてみます。
どのレイヤーでデータを処理するべきか
どのレイヤーでデータを処理するべきかについてですが、可能な限りDBに近い場所でデータを加工した方がシンプルになります。
必要なデータ処理がDBのレイヤーで行われていれば、後のレイヤーはただそれを Key ValueのペアのオブジェクトとしてそのままViewに返し、Viewに表示すれば良いだけです。
じゃあ何故複雑になるの？
DBのレイヤーでデータが加工できれば一番楽です。
しかし、何故それが出来ないのでしょうか？
理由1 DBの中に複雑なロジックを持つのが難しいため
一つ目は、DBの中で複雑で動的な処理を記述するのが難しいためです。
例えば、Mysqlで一つのrowでfirstNameとlastNameを参照したfullNameというgetter的なカラムを定義することはできません。getter的な挙動ができるのはクエリ文か、もしくはクエリを発行するためのModelにロジックを定義する事になります。
この時点で、DBに対してクエリを発行する事で得られる値と、モデルに対してメソッドにメッセージを送る事で取得できる値の2パターンのが存在する事になります。
Modelで持つには複雑すぎるロジックの場合は、更にコントローラーなどのレイヤーにロジックが登ってきます。
上で書いたようなレイヤーのどこでロジックを書くか、常にそれを頭に入れないといけない事になり収集がつかなくなります。
理由2 メッセージを送るのがビューからになるため
取得したいデータ形式を決めるのはDBじゃありません。Viewです。DBから一番遠くにいるViewです。
データの加工をよりDBに近いレイヤーで実行するためにはクライアントで定義した情報が可能な限りDBのレイヤーまでシンプルに届く必要があります。
しかし、クライアント、ルーティング、コントローラー、モデルまでがシンプルで汎用性のある設計になっていなければ、取得したいデータの定義に関する情報は途中のレイヤーに止まってしまいます。サーバーサイドで処理することもあればクライアント側で処理するデータもあるといった歪な状態になってしまいます。
解決のための設計方針
クライアントからのメッセージを可能な限りDBに近いレイヤーに届くためのインターフェイスを作る事です。
クラアイアントからのメッセージング(どのテーブルのフィールドを取得したいか、どのような件数を取得したいか、どのようなステータスのデータを取得したいかといった情報)がDBのクエリに届くように反映され、かつセキュリティー要件が満たされる事。
そんな夢のような事できないよ
その通りだと思います。仮にセキュリティーを全く考慮しなくて良いならば世界に一つのDBに対してクライアントから直接クエリを発行するだけで済むかもしれません。
しかし、現実はそうではないので幾重にもレイヤーを重ね、各レイヤーで汎用的な処理を記述できるように頑張るのだと思います。
簡単ではないですが、基本的な方針としてはメッセージングが可能な限りDBの近いレイヤーに届くようにAPIを設計する事を考え、それを実現するための設計手法を得ていく必要があるのではないでしょうか。
終わりに
殴り書きなのに読んでいただきありがとうございます。
CSSだけ、HTMLだけ、などの一つの機能を見ると処理の抽象化などが不要に見えるのですが、複数の機能の関係性を扱うと指数関数的に問題が難しくなります。
最初の頃はあまりプログラミングの設計力に意識が向かないかもしれないですが、少しでもいい設計への問題意識が高まると良いなーと思います。