マルチレイヤアプリケーションのモデルの命名規則

Question

私は新しい開発者です。私は大企業の会社で働いたことがないので、多層アプリケーションの命名規則に関する質問があります。 WPF/MVVMアプリケーションがあり、EFデータレイヤーがあります。私はまた、DDDの原則を調整したい。

だから私は同じクラスの3つのモデルを私は言うだろう。私はMVVMの "モデル"を持っている、私はエンティティ/ dto（私は知らない？）EFで、私はドメインモデル/ DOCのPOCOを持っています。私はこれらの3つのクラスをすべて別々に作成しなければなりません（MVVMモデルとPOCOをマージすることができますが、POCOはMVVMのモデルです）。どうすればいいのですか？

私はPerson POCOを持っているとしましょう。それはEFの "Person"か "PersonDto"でしょうか？一般的な大会は何ですか？私はpostfixを使って両方の方法で出会ったので、混乱しています。

Answer 1

通常、DTOとReadModels/ViewModelsの後に接尾辞を付けますが、ドメインオブジェクトには接尾辞を付けません。

厳しいルールはありません。個人（チーム）の好みの問題です。名前空間の代わりに名前空間を使うのが好きな人もいますが、それほど明白ではありません。

編集は：ところで、私は別の「永続化モデル」を有するのnot a huge fanだ（と私はnot the only oneです）。そして、どんな場合でも、私はそのレイヤー内のオブジェクトを呼び出さないでしょうDTOのです。

Answer 2

私は次の記事に出くわしました。私のプロジェクトのクラス/エンティティに名前をつけているうちに私は意味があります。

Naming Conventions - XAML made easy

私はそれがあまりにも

Answer 3

DTOをお手伝いしますhople：例えば：PersonDto

A DTOは、データが ネットワークを介して送信される方法を定義するオブジェクトです。

POCO：例えば：Person

Entity Frameworkのは、データ クラス自体に何らかの変更を加えることなく、データモデルと一緒に をカスタムデータクラスを使用することができます。つまり、既存のドメインオブジェクトなどのオブジェクト（POCO）をデータモデルに使用することができます。 データモデルで定義されたエンティティにマップされるこれらのPOCOデータクラス（パーシスタンス無視のオブジェクトとも呼ばれます） は、エンティティ 型と同じクエリ、挿入、更新、および削除動作の大部分をサポートします（ ）。エンティティデータモデルツールによって生成されます。

ご希望の場合は、こちらをご覧ください。

Answer 4

また、DDDの原則を調整したいと思います。

ドメインモデルで使用される名前は、ドメイン専門家のユビキタス言語と一致する必要があります。

Answer 5

人が人ではないことを覚えておくことが重要だと思います。あなたがそれらを分離したい理由は、彼らが非常に異なることをするかもしれないからです。

たとえば、私は学生のドメインが

オブジェクト、その後、フロントエンドは、学生のためのAddressChange更新を送信するためにマップするデータベースクラス/オブジェクト

（のサブセット）

人々を持つことができます。

もちろん、Person、PersonDTO、PersonDB、さらにはPersonVMを使用することもできます（フロントエンドでjavascriptのタイプを使用しているとします）。覚えておくべきことは、「完全に異なっている」ため、それらを分けることです。あなたがそれらを常に正確に同じものにすることを強制するならば、それらを分離する本当の理由はありません。