Aurelia-frontendを使用したDjangoバックエンド。 DRY原則に違反しているモデルをそれぞれ定義していますか？

Question

私の最近のプロジェクトでは、DjangoバックエンドでAureliaフロントエンドを試してみたいと思います。 Djangoでいくつかのプロジェクトを行い、バックエンドにDjango REST APIを使用したいと思っています。
私はAureliaを初めてお使いになり、数回ドキュメントを読んでいます。

Aureliaフロントエンドで、ニックネーム、電子メール、モバイル、アドレスなどのモデルを明示的に定義するのがよいかどうかは、Djangoではすでにモデルで定義していますデータベースの.py。私は/私のDjangoアプリケーションにAPIを介してデータをフェッチするので、おそらくそれを省略することができます。 ドキュメントのAurelia「開始」セクションでは、ToDoモデルを別ファイルで定義しましたが、データはデータベースには添付されませんでした。これをやっていることは私には2回（バックエンドとフロントエンドで）やりたいことがあり、DRYの原則に違反しているようです。

あなたは何が良い習慣だと思いますか？あなたのお勧めをありがとう！

Answer 1

クライアント側でクラスを定義することには利点があります。まず、レスポンスデータをクラスインスタンスにマップし、そのような方法でデータを操作します。しかし、JSONオブジェクトを使って作業するのは難しくありません。

第2に、クラスをJSONにシリアライズするのは簡単です。さらに、いくつかのバックエンドフレームワークでは、非常に特別な形式のJSONオブジェクトが必要です。時にはクラスがそれを実行する唯一の実用的な方法です。

第3に、私が知る限りJSONオブジェクトではできないクラスでできることは、メソッドや関数を追加することです。その拡張性だけでも努力する価値があります。

バックエンドとフロントエンドでクラスを定義することは確かに珍しいことではありません。私はAureliaとAngularで仕事をしていますが、どちらもうまく働いています。クライアント側のクラスを持たないAureliaアプリを作った。私が実際にそこで見逃したのは、IDEにエクスポート/インポートされていないのでIntellisense（4番目の利点）はありませんでした。ところで、私はVSコードを使用します。

DRYがいいです。しかし、意図を示すことは、特に、他の人がコードを完了したときにコードを取り上げると、長い道のりを歩むことができます。クラスがそこで助けることができます。第5の利点は、意図を示すのに役立ちます。

最後に、もっと多くの利点があると確信しています。

結論：クライアント側のクラスを使用することをお勧めします。後悔しない。

希望すると便利です。