core-data - 一部のインスタンスを変更できないことをモデル化するにはどうすればよいですか?

Question

xcode とコア データを使用してデータ モデルを作成しています。これはエンティティ関係モデルではなくオブジェクト グラフであるため、継承と多対多の関係があります。

これが私の問題です。Category というクラスまたはエンティティがあります。一部のカテゴリはアプリによって作成され、ユーザーが削除または変更することはできません。ユーザーは独自のカテゴリを作成できます。

それについて考えた後、これをモデル化する 4 つの方法を見つけました。写真を見てください：

フラグ isSystemCategory を追加するのが最も実用的な解決策だと思いますが、モデリングの観点からはどのような解決策が最適なのだろうかと思います。私は最初のものを推測します。Category と呼ばれる抽象クラスと、編集および削除可能な UserCategory と不変の SystemCategory の 2 つの子孫であり、ユーザーはそれを削除または変更できません。子孫は属性、関係、または変更を追加しないことに注意してください。それが私の質問の理由です。これはモデラーにとって正しいアプローチですか?

あなたのアイデアを知りたいです。ありがとう。

Answer 1

説明に基づいて、私はおそらく最初のものにも行きます。

子孫は属性、関係、または変更を追加しないことに注意してください

しかし、振る舞いは異なります。また、論理的な違いもあります。User と UserCategory の間には、ユーザーが UC を作成/更新/削除できる暗黙の「関係」があります。これを明示的に保持する必要はないかもしれませんが、それでもそこにあります (たとえば、誰がカテゴリを作成/変更/削除したかを記録したい場合は、それをキャプチャすることができます)。

個別のサブタイプを作成すると、フラグなどを使用した場合に発生する厄介な条件付きロジックのかなりの部分を防ぐことができます。削除を考えてみましょう: フラグを使用すると、if (category.isUserCategory) then <delete> else <...etc...>. さらに、そのロジックは、ユーザー カテゴリとシステム カテゴリで異なる動作をする操作ごとに複製されます。サブタイプを使用すると、それが削除されます。実行するだけUserCategory.delete()で、SystemCategory.delete()実行しないだけです (SystemCategory の公開削除さえない可能性があります)。条件なし。

最後に 1 つ考えてみましょう: ここでの問題は、実際には認可に関するものです。カテゴリを扱うことが唯一の場所である場合、オプション（1）はおそらく実用的な解決策です（「機能する可能性のある最も簡単なもの」）。ただし、アクセスを制御する必要が繰り返しある場合は、より一般的な承認メカニズムを使用する必要があります。

h番目。