データの型を統一する

前回の記事で、any型を排除してPrismaの型を使うようにしたと紹介しました。 今回は、なぜ「Prismaの型を優先する」というルールを設けているのか、 もう少し詳しく説明します。

書類のフォーマットを想像してみてください

学校には様々な書類があります。 出席簿、成績表、保健調査票...。 もし、これらの書類で「生徒の名前」の書き方がバラバラだったらどうでしょう。

同じ生徒なのに、書き方が違う。 これでは、書類を照らし合わせるときに混乱します。 だから学校では、書類のフォーマットを統一しています。

プログラムでも同じです。 「生徒」のデータをどんな形で扱うか（どんな項目があるか、 それぞれ何が入るか）を決めておく必要があります。 これを「型」といいます。

型が乱造されると何が起きるか

問題は、開発者が自由に型を作れてしまうことです。

たとえば、Aさんが「生徒一覧画面」を作るときに 「StudentData」という型を作る。 Bさんが「成績表出力」を作るときに 「StudentInfo」という型を作る。 どちらも「生徒」のデータを表していますが、微妙に違う。

これは実際に起きやすい問題です。 「とりあえず今必要な形で型を作ろう」と思うと、 どんどん似たような型が増えていきます。

「Prismaの型を使う」というルール

一括採点では、この問題を防ぐためにルールを設けています。「できる限りPrismaの型を使う。独自の型は作らない。」

Prismaは、データベース（SQLite）とプログラムをつなぐ道具です。 データベースの設計から、型が自動で生成されます。 この自動生成された型を「唯一の正解」として、プログラム全体で使います。

「生徒」のデータを扱うなら、Prismaが生成したStudent型を使う。 画面で表示するときも、ファイルに書き出すときも、同じ型。 独自に「StudentData」や「StudentInfo」を作らない。 これがルールです。

2つの部分で同じ型を使う

以前の記事で紹介したように、一括採点は「メインプロセス」と「レンダラープロセス」という 2つの部分がデータをやり取りしながら動いています。

この2つの間でデータを受け渡すとき、 もし別々の型を使っていたらどうなるでしょう。 送る側が想定している形と、受け取る側が期待している形が違う。 これはバグの温床です。

だから、メインプロセスでもレンダラープロセスでも、同じPrismaの型を参照することをルールにしています。 「生徒のデータを送る」なら、送る側も受け取る側も同じStudent型を使う。 型が一致していることをプログラムがチェックしてくれるので、 「送ったデータと受け取ったデータの型が違う」というバグを防げます。

独自の型を作っていい場合

とはいえ、すべてPrismaの型で済むわけではありません。 以下の場合は、独自の型を作ることが許されています。

「データベースに保存するデータ」については、Prismaの型を使う。 「画面だけで使う一時的なデータ」については、独自の型を作ってもよい。 この区別がポイントです。