たとえば、私のプログラムは投稿を削除する機能を提供したいと考えています
投稿には(写真、テキスト、投稿のコメント)が含まれています
私の当初のアイデアは、最初に画像のテキストを削除してからコメントを削除する関数を使用することです
ただし、このような関数のコードは非常に長く、ほぼ 100 行以上あり、if else の山はめまいを感じさせます。また、途中で実行エラーが発生すると面倒なので、写真を削除する際にQiniuインターフェースを呼び出して削除するので、ネットワーク障害の可能性も否定できません
だから、マスターが後のメンテナンスを容易にし、事故を完璧に解決するための設計アイデアを提供できることを願っています
たとえば、私のプログラムは投稿を削除する機能を提供したいと考えています
投稿には(写真、テキスト、投稿のコメント)が含まれています
私の当初のアイデアは、最初に画像のテキストを削除してからコメントを削除する関数を使用することです
ただし、このような関数のコードは非常に長く、ほぼ 100 行以上あり、if else の山はめまいを感じさせます。また、途中で実行エラーが発生すると面倒なので、写真を削除する際にQiniuインターフェースを呼び出して削除するので、ネットワーク障害の可能性も否定できません
だから、マスターが後のメンテナンスを容易にし、事故を完全に解決するための設計アイデアを提供できることを願っています
投稿に写真、テキスト、コメント、その他の関連情報が含まれている場合。
その後、それらを削除したい場合は、写真の削除、テキストの削除、コメントの削除の関連する SQL ステートメントを記述する必要があります。これは避けられません。 その後、残りの問題は、そのような機能を拡張および維持する方法です。
オブザーバー モード を作成することを強くお勧めします。削除後の操作がトリガーされると、写真、テキスト、コメントの削除に関連する操作がトリガーされます。このようにすると、結局のところ、1つのメソッドに1つのメソッドが対応しており、それほど多くのif判定を記述する必要がありません。
投稿のステータスを設定できます: 表示、非表示、削除
削除時は削除状態に設定されるだけでフロントエンドには表示されません
次にスケジュール実行スクリプトを入れてステータスが削除された投稿を完全に削除します
すべての削除は論理的な削除ですが、なぜ物理的な削除を行う必要があるのですか?
実際、7Niu の安定性は非常に優れており、ネットワークの問題についてあまり心配する必要はありません。削除を開始するときに、削除されたフィールドをテーブルに追加することもできます。ローカルで 1 に設定し、リモート削除後にコールバックします。それ以外の場合は、スケジュールされたタスクが delete=1 でデータを 2 回クリーンアップするのを待ちます。
テキストやコメントなどについては、追加の処理を行わずに直接カスケードで削除できるように、外部キーを使用して投稿に関連付けるのが最善です。または、ORM クラス フレームワークでモデルを宣言するときに依存関係を指定し、カスケード削除を自動的に完了することもできますが、とにかく手動処理では不十分です。
その後、とにかく大きなファイルではなかったため、削除しませんでした。