問題タブ [domain-model]

データ モデル (.edmx ファイル) があります。このファイルを使用して、エンティティ フレームワーク ツールを使用してドメイン モデルと XML マップを自動生成するにはどうすればよいですか?

ドメイン モデル: クライアント アプリケーションのデータ アクセス層コンポーネントが使用するドメイン モデル。

XML MAP: データ構造の XML/XSD 表現。

私はSpringの本を勉強していますが、彼らはJavaドメインモデルについて言及しています。
それは何ですか？

私は、すべてのロジックが aspx ページの分離コードに配置されている Web フォームの世界から来ています。ASP.NET MVC に関する本を何冊か読んだり、ポッドキャストを聞いたり、Tekpub でビデオを見たりした後、少し違った方法でアプローチする時が来たと判断しました。

残念ながら、私はすでに立ち往生しています。

複数のWebサイトを追加できる、ある種の小さくて基本的なCMSを構築しようとしています。

コントローラーを薄くしておく必要があることはわかっているので、これを行うにはある種のサービス クラス (WebsiteService と呼びましょう) を使用する必要があると思います。私はデータ アクセスに Entity Framework を使用しており、ビューはすべて特定の ViewModel を使用しています。Web サイトを作成または編集すると、次の 4 つのことが起こるはずです。

• 入力を検証する
• Web サイトに関する情報をデータベースに追加します (編集の場合は情報を更新します)。
• ディスク上にディレクトリを作成します（編集の場合はディレクトリの名前を変更する可能性があります）
• ホスト ヘッダーを IIS Web サイトに追加します (古いホスト ヘッダーを削除し、編集の場合は新しいホスト ヘッダーを削除できます)。

基本的に、WebsiteService はより高度な検証を実行し、データベースに書き込み、ディレクトリを作成/編集し、ホスト ヘッダーを追加/削除し、成功したかどうかを示すために何かをコントローラーに返す必要があると思います。

このクラスはどのように見えるべきですか? 答えがわからない質問がいくつかあります。

1. WebsiteService も CreateWebsite ViewModel を実際の Website クラスに変換する必要がありますか、それとも、WebsiteService が実際の Website オブジェクトを受け入れるようにするために何か他の方法でこれを行う必要がありますか?
2. 基本的な入力検証は、ViewModel の Validation 属性を使用して行われます。より広範な検証 (「データベースにこのドメイン名の Web サイトは既に存在しますか?」) も行う必要があります。WebsiteService もこれを行う必要がありますか?
3. 3 つの手順 (データベースへの保存、ディレクトリの作成、IIS へのホスト ヘッダーの追加) はすべて 1 つのパブリック メソッド ( WebsiteService.SaveWebsite(ViewModels.CreateWebsite website)) で実行する必要がありますか、それともコントローラーが呼び出す必要がある別のメソッドを提供する必要がありますか? （呼び出し順序が重要だと思うからではないと思います。）

私たちは、MSSQLデータベースから「データベースファースト」アプローチで生成された複数のプロジェクト/アセンブリにわたっていくつかの関連するドメインモデルを生成できるようにするORM/ドメインモデリングツールを求めています。どのツールが私たちのニーズを満たすかを理解するために、いくつかの助けが必要です。

要件は次のとおりです。

1. プロジェクト間の関係

   • 私たちのドメインは多数のモジュールに分割されており、クライアント（ソースコードを提供するクライアント）ごとにすべてのモジュールを使用するわけではないため、クライアントが表示したりアクセスしたりする必要のないすべてのロジックを「プラグを抜く」必要があります。 。
   • たとえば、共有データ（主に一般的なルックアップ情報）を独自の共通アセンブリに格納する必要があります。
   • モデル間に双方向の関係は必要ありません（循環参照が発生するため）。子の関係の終わりのみが生成されます。

2. プロジェクト間の継承

   • 上記と同様に、共通の機能を1つのドメインモデルの基本クラスに抽象化し、それらを継承できるようにする必要があります。
   • 注：ドメイン間の継承リンクは制限され、サブドメインごとに1つまたは2つだけになります。
   • 注：問題ではありませんが、「タイプごとのテーブル」または「クラステーブル継承」を使用して、リレーショナル（DB）スキーマで継承をモデル化しています。

3. 生成されるクラスは次のとおりです。

   1. DataContract/DataMember属性でマークされています
   2. プロパティの変更を通知する（INotifyPropertyChanged実装を介して）
   3. 部分的なOn*PropertyName * Changed（）メソッドがあります（たとえば、Linq toSQLおよびEntityFrameworkで生成されたオブジェクトに従って）
   4. （理想的ですが、必須ではありません）関連するコレクションタイプは、INotifyCollectionChangedを実装する必要があります。

これらの基準をサポートする（またはサポートするための回避策がある）ORMツールに関するフィードバックをいただければ幸いです。

注：これまで見てきたツール（ただし、これで完全に除外されるわけではありません）：

• LightSpeed（素敵ですが、プロジェクト間の継承を簡単にサポートしていません）。
• LLBLGen（複雑ですべてを網羅していますが、AsSeparateProjectsモードを使用してグループ化すると、継承はもちろん、モデル間の関係もサポートされていないようです）。
• Entity Framework（私は迷子になりました...ドメインを複数のモデルに分割したときのデザイナーの話はあまり良くありませんでした）。

ドメイン オブジェクトでデータベースの制約をテストする必要がありますか? たとえば、データベースのフィールドが varchar(500) で必須の場合、コードでこれをテストする必要がありますか? それとも、try/catch に頼るべきでしょうか。

回避できれば、作業のかなり大きなオーバーヘッドになります。

いえ

この質問で十分にカバーされているSystem.Uriように、URIに対する私の意図を反映するための良い選択です。しかし、電子メールアドレスはどうですか？

プロパティMailAddressに追加の情報が含まれているため、あまり明確ではないようです。DisplayName

これは多かれ少なかれ一般的な質問であり、特定のORMや言語に関するものではありません。この質問はORMの好みに関係なく出てきます。

多対多の関係をマッピングする場合、中間テーブルを隠したり、中間テーブルをモデルの一部にすることができます。中間テーブルに関係を超えた貴重なデータがある場合、マッピングをどのように処理しますか？

次の表を検討してください。

プログラマーとして、私は実際にできることを望んでいます。

よりも

一方では、テーブルCaseWorkerCasesには有用なデータが含まれており、中間テーブルを非表示にすると、そのデータへのアクセスが不便になります。一方、中間テーブルをナビゲートする必要があると、Casesにアクセスする一般的なタスクが厄介に見えるようになります。

1つの解決策は、モデル内の中間テーブルを公開してから、CaseWorkオブジェクトにラッパープロパティが機能するようにすることだと思います。何かのようなもの：

しかし、それも間違っているようです。

I have a type that is constructed using information from various domain entities.

The type itself is present because within some contexts in the system it is useful and meaningful to abstract away from the large and complex legacy types that supply the information for the type. It exposes a subset of the fields of the types used to instantiate it, plus it contains some functionality of its own.

The type has its own service, providing a creation method, that under the hood, coordinates the creation and persistence of the domain entities that make up instances of the type.

Is there a name for the concept of such a type?

It is certainly an aggregate of some kind. It is certainly a kind of domain model, but it is a facade onto other domain models.

In a greenfield system I suspect the need for such a type would be limited, but I have found it to be useful when dealing with inflexible legacy codebases.

私は依存性注入の初心者です。私は一度も使用したことがなく、それが何であるかを正確に理解することさえありませんでしたが、このトピックに対する最後の攻撃の後、オブジェクトとその依存関係を切り離す方法であることがわかりました。コンテナが私たちに代わってそれを行い、準備ができたオブジェクトを私たちの手に届けるようになりました。

ポイントは次のとおりです。「いつ使うべきですか？」、常に??? 実際、私は初心者で、このパターンを使用するプロジェクトを見たことがないので、ドメイン オブジェクトにどのように適用すればよいかわかりません!!! オブジェクトをインスタンス化することは二度となく、コンテナが常にインスタンス化するように思えますが、疑問が生じます...

1) たとえば、依存関係の一部が UI に由来する oobjects についてはどうですか。

UI からユーザー名を取得するとしたら、conatiner はどのようにしてそれを認識し、このオブジェクトを配信するのでしょうか?

2）私が直面している他の状況があります。依存関係が既にインスタンス化されているオブジェクトである場合、たとえば... SINGLETON オブジェクトなどです。注入される依存関係の有効範囲に関する設定があるのを見ました（Spring.NETについて話している、たとえばhttpリクエストスコープ）...しかし、リクエストおよびその他のWeb関連のものは私のプレゼンテーションレイヤーにあります。デザインルールを破ることなく、プレゼンテーションレイヤーとドメインレイヤーの両方をリンクします（ドメインは、レイヤーの依存関係を持たないように、どこで消費されているかを完全に認識しない必要があるため）

皆さんからのご連絡をお待ちしております。どうもありがとう。

ついにドメインモデルを構築しています。ドメインモデルには、ドメインオブジェクトを永続性に緩く結合するためのインターフェイスが含まれています。ただし、ドメインモデルオブジェクトを相互にどのように結合する必要があるのか​​疑問に思っています。

注文は顧客を指しますか、それともICustomerを指しますか？

この投稿では、オブジェクトを積極的にデカップリングする際の問題について言及しており、「[インターフェイス]を使いすぎてしまう」ことを思いとどまらせているようです。ただし、ドメインエンティティが依存している他のエンティティをモックできない限り、ドメインエンティティを実際に単体テストする方法がわかりません。これには、緩い結合が必要です。

また、ピースを交換できるドメインモデルがどれほど現実的かについてもわかりません。