kimuson.dev

型安全にクエリ発行できて便利な Prisma だけど、Prisma Client の戻り値がプレーンオブジェクトであるためメソッドを生やせないつらみがある

例えば適当なサービスのユーザーのドメインモデルがあるとして

ts
class UserModel {
  id: number;
  firstName: string,
  lastName: string,

  fullName() {
    return `${this.firstName} ${this.lastName}`;
  }
}

の fullName 実装が Prisma だと書けないよね〜という話

僕はサーバーサイドは NestJS で書くことが多くて、だいたい user.service.ts に getUserFullName(user: User): string とかを生やすことになる or 使いたい箇所で愚直に書くになるのでつらい

ざっくり 2 方針

Explore how to extend the Prisma Client · Issue #7161 · prisma/prisma · GitHub

この辺りの Issue で議論されてるけど、すぐに Prisma 側でなにかをサポートする形にはならなそうなのでこちら側でなんとかしたみ

とりえあず 2 方針うかぶのでやってみる

クラスにマッピングする
後付けでオブジェクトにメソッドを生やす

クラスにマッピングする

拾ってきたデータをクラスにマッピングしてあげる

user.model.ts
import type { User } from '@prisma/client'

class UserModel<Data extends User> implements User {
  id: number;
  firstName: string;
  lastName: string;
  friendId: number | null;

  private data: Data;

  constructor(data: Data) {
    this.id = user.id;
    this.firstName = user.firstName;
    this.lastName = user.lastName;
    this.friendId = user.friendId;
    this.data = data;
  }

  fullName() {
    return `${this.firstName} ${this.fullName}`;
  }
}

こんな感じでクラスにマッピングすればメソッド生やせる

ただやっぱりクラスだと柔軟性がワンランク落ちてしまうというのはあって、例えば Prisma だと例えば A JOIN B で拾ってきたら A & { b: B } で型解決される（データも拾ってこられる）けど、クラスでこれを表現しようと思ったら使用するリレーションのパターン分モデル作る(AModel, AWithBModel, ...etc)しかないのでなんともなーという感じ上の例だと一応 data にデータおいてて型も残してるので参照自体はできるけど、リレーション先に依存したメソッドははやせない(hoge() { this.relationProp でなにか } ができない) あと Prisma だとスキーマを schema.prisma に書いていくので重複で同じくスキーマみたいなものをクラスで書くのは冗長な気もかなりする

オブジェクトに生やす

JS のオブジェクトはメソッドはやせるから

js
const user = {};
user.method = () => {
  console.log("Hi");
};

型解決できるならこれでも良いはず

→ Vue とか config 系でよく使われる defineXXX のパターンで型解決はできる

アプリケーションコードでは ↓ の感じで実装できる

user.methods.ts
import type { User } from '@prisma/client'
import { defineMethods } from 'path/to/prisma-util'

const userMethods = defineMethods<User>()({
  // 補完はちゃんと効くので、ストレスなく拡張メソッドを定義できる
  fullName() {
    return this.firstName + ' ' + this.lastName
  },
  otherMethod() {
    this.fullName()  // 別のドメインメソッドでも型解決できる
  }
})

export const withUserMethods = createWithDomainMethod<User, UserMethod>(userMethods)
export type UserMethods = typeof userMethods
export type UserModel = ReturnType<typeof withUserMethods>

user.service.ts
import { Injectable } from "@nestjs/common"
import { PrismaService } from "~/path/to/prisma.service"
import { UserModel, withUserMethods } from './user.methods.ts'

@Injectable()
export class UserService {
  constructor(private prisma: PrismaService) {}

  async fetchUser(): Promise<UserModel | undefined> {
    const userData = await this.prisma.user.findUnique({ where: { id: 'id' } });
    if (userData === null) return;

    const user = withUserMethods(userData);
    user.fullName();  // 生やしたメソッドが型安全に使える
    return user;
  }
}

上のプレイグラウンドに書いたけど、こっちのやり方ならリレーション先にもメソッドを生やす＆型解決したりができる

ts
const userWithFriend = withUserMethods(userWithFriendData, {
  friend: withUserMethod,
});

ので、クラスベースじゃないから Prisma が解決してくれる柔軟な型定義とデータ構造を生かしやすいのはこっちかなという気がする

比較する

スキーマの再定義の必要もない
リレーション先のメソッド生やすのも割とスマートに解ける

ので基本的には後者のやり方でヘルパ使ってメソッド生やすのがすっきりすると思う

ただ NestJS で使う前提なら class-validator, class-transformer を使ってバリデーションとか表示データへの整形（Presenter 層っぽいこと）とかをやるし、コードファーストならクラスで書かないと OAS 作れないしでいずれにせよドメインモデルをクラスで定義する必要があるので

repository: prisma を使ってクラスで再宣言したドメインモデルを返す
service: prisma に依存せず、repository から受け取ったドメインモデルでビジネスロジックを書く

とかにしてしまうのがスマートな気がする

結論

NestJS 等、Prisma に限らずドメインモデルをクラスで書きたいモチベーションがあるならマッピングする
それ以外なら、受け取ったオブジェクトに後付けでメソッドを生やす

が良さそう

Prisma でメソッドはやせない問題どうしたらいいんだ

ざっくり 2 方針

クラスにマッピングする

オブジェクトに生やす

比較する

結論

見出し