今回はECサイトを作成で学んだことを5つに分けて記事にしていきます。
以下の箇条書きの記事をそれぞれ作成します。
記事が出来次第、リンクへ変更になりますのでお待ちください。
- エンジニアリングについて
- Djangoについて
- Pythonの文法
- 汎用ビューについて
エンジニアリングについて
今回は3つのことを学びました。
- セッションの適切な使い方
- Fat Viewの誕生
- トランザクションの使い所
セッションの適切な使い方
私が作成したECサイトでは割とセッションを使いました。
Userの判別
結論、今回はカートでユーザを判別しました。
普通なら User テーブルを作成してユーザに必要な情報を設定させユーザ名に unique 制約をつけて判別をすると思います。
しかし今回は User テーブルを作成せず、カートページに遷移したらセッションを発行するようにして、会員登録はしないようにしました。
プロモーションコードの一時的な格納
プロモーションコードを適用する際に以下のメリットがありました。
- DBに保存せずデータの管理ができた
- 毎回クエリを発行せずに済むのでパフォーマンスが良い
- カートに紐づく形でプロモーションコードを保持
- チェックアウトまで保持が可能
ただDBに保存しないデメリットもありまして、
セッションが切れたらコードが消えてしまうことです。
しかしプロモーションコードの性質上、一時的な管理が適しているため今回は問題ないと判断しました。
Fat Viewの誕生
今回、私のコードがコードを書いた際にCTOからレビューいただきまして気づきました。それは、Fat View になっていたことです。
一例としてCartクラスのget_context_dataメソッドでFat Viewが誕生しました。
ここではざっくり以下のことをしていました。
- カートオブジェクトを取得 or 作成
- カート内の商品を取得
- バリデーションエラーを取得
- 商品情報を取得
- プロモーションコードを取得
データを取得すること目的ですが
私はカート内の商品ごとの小計の計算やカート内の商品の個数の計算を
Viewで行っておりました。
このようになってしまった原因は以下のことが考えられます。
- 何も考えずViewに殴り書きをした
-
get_context_dataが何をするメソッドなのかを理解せずに書いた - modelはDBのカラム制約（unique, max_lengthなど)だけ書けばいいと誤認していた
以下の記事にて私はViewの役割をはっきりとさせました。
別記事にてget_context_dataは紹介します。
トランザクションの使い所
まずトランザクションとは
一連のDB操作を「ひとかたまりの処理」として扱うことです。
以下のようにALL or Nothingの状態です。
全ての処理が成功 → データを確定
途中でエラー発生 → 変更を取り消す
ここでは詳しい説明は割愛しますので、詳しくは以下のURLよりご覧ください。
今回のECサイトでは
購入処理の部分でトランザクションが必要となりました。
以下が機能フローです。
- 請求先住所保存
- 支払い情報保存
- 注文情報保存
- カート内商品保存
- メール送信
- プロモーションコードを使用済みに変更、使用日時を購入日時とする
- 新しいプロモーションコードを作成
- カートを削除
この8つを「ひとかたまり」として実行するようにしました。
また今回はDjangoのwith構文を使い
with transaction.atomic()として実行しました。
用途やシステムの複雑さによってwith構文ではなく
デコレータや他の実装方法になることもあるでしょう。
最後に
今回はECサイト作成で学んだこと①ということで
エンジニアリングについて記載しました。
次回はDjangoについてを書きます！