問題タブ [entity]

イベントを使用して簡単にPropertyChangesフラグを設定できます。しかし、に保存した後、どうすれば簡単にリセットできますObjectContextか?

XML を XmlDocument にロードする場合、つまり

プロセスがエンティティを置き換えるのを止める方法はありますか? TM 文字に変換される xml に TM 記号 (エンティティ #8482 として格納) があるという奇妙な問題があります。私に関する限り、XML ドキュメントには ISO-8859-1 (TM 記号がない) のエンコーディングが含まれているため、これは発生しないはずです。

ありがとう

コンテキスト: だから、とてつもなく複雑なドメイン モデルを構築しようとしています。ユーザーと話すと、システムの使用方法は複数あります（たとえば、従業員の観点からの方法と、雇用主の観点からの方法など）。実際には、コア ドメインを再利用する複数のアプリケーションです。

質問: 複数の観点からドメインを作成するのは間違っていますか? たとえば、ビジネスの運営に合わせてドメインを構築するということは、エンティティなどに関する追加情報を保持するあらゆる種類の関係クラスを作成することを意味します。リレーションシップ クラスは、親エンティティにロールバックできます。

アイデア？反論？私は完全に基地外ですか？

エンティティ、正確には動的エンティティに存在する属性名とタイプを取得しようとしています。次のコードがあります。

プロパティのカウントが 0 になっています。

ID を連絡先エンティティに渡すことは必須ですか。エンティティの属性をExcelファイルから取得した属性にマップしようとしているためです。エンド ユーザー自身がマッピングを行うので、必要なのは属性名とタイプだけです。たとえば、SQL には次のクエリがあります。

このクエリは基本的に、フィールド名のみを含む空の結果セットを返します。それが私がここで探しているものです。それは可能ですか？

そのため、サービスとして実行するマルチテナント システムを構築しています。私たちはゼロから始めています。私たちは DDD に従っています。ドメインには (現時点で) ~20 個のエンティティがあり、後でさらに増える予定です。それは私たちによってホストされ、地理的に冗長であり (SQL クエリを除くすべての n+1 ;-))、柔軟な設計です (まあ、最後は私たち自身の要件であり、ビジネスではありません)。もちろん、必要に応じて簡単に変更できます）。私たちは .NET ベースで、バッキング ストアにリレーショナル データベースを使用します。オープンソースのツールやライブラリを使用することに (まったく) 反対しているわけではありません。

ビジネスに不可欠な機能の 1 つは、特定のエンティティがシステムのテナントによって拡張可能であることです。たとえば、クライアント A はエンティティ Foo に Title および Abstract プロパティを持たせたい場合がありますが、クライアント B はエンティティ Foo に Title Abstract ではなく Publish Date および Directed-By プロパティを持たせたい場合があります。

また、これを必要とするテナントのために複数の言語でデータをサポートする必要がある場合もあります。「静的」文字列と、エンティティにデータとして添付された文字列の両方。

そう。任意の数のフィールド (いくつかの共通のベースラインの上にあり、すべてのテナントが取得するこれらのエンティティに関する特定のものがあります)、クライアントによって定義可能です (データ型も定義できます)。データの翻訳の可能性 (エンティティを複製せずに、英語で 1 つのセットを設定せずに、フランス語で同じセットを設定せずに)。厳密に型指定された検索可能でクエリ可能なバッキング ストレージも (したがって、厳密に型指定され検索可能になる方法がない限り、XML フィールドに余分なものは入れられません)。高性能（ただし、二次的な要件として。機能は、必要に応じてハードウェアを購入するのに十分重要です）。

データ量？現在のシステムでは、「平均的な」クライアントには数百のエンティティがあり、「大きな」クライアントには数千のエンティティがあります。通常、要求はこれらのリストを 10 から 200 程度に絞り込んで表示します。最も一般的にやりたいことは、おそらく半ダースのエンティティ (新しいシステムでは拡張可能である必要があります) です。

その他のポイントは？各エンティティには、それを所有するテナントへの直接リンクがあります。

.NET ランドでこれを行うにはどうすればよいでしょうか。エンティティを IoC コンテナーに入れ、実行時にその場でまとめてグロブ化することが提案されていますが、それをリレーショナル データベースにどのようにマッピングすればよいでしょうか。

また、かなり前に Lucene.NET に関するAyende の投稿を読んだことも覚えていますが、これは良さそうですが、現時点では Lucene.NET や nHibernate を使用した経験はありません。(現在、ORM に Linq2Sql を使用する予定ですが、これをサポートするためにそれを変更する必要がある場合は、率直に言って、私は個人的に喜んでいます)。

Ayende からリンクされているこの Castle dev list スレッドを読みましたが、nHibernate には IUserType と呼ばれるものがあり、これが役立つようです。それを適用して、各テナントに適切な IoC を取得することができるのでしょうか? したがって、拡張可能エンティティごとにテナントごとに 1 つの IUserType を作成し、データ自体を SQL Server (最も可能性の高い RDBMS) 内の XML 列に格納します。

最後に、テナントごとのエンティティごとに DB テーブルを動的に変更することに関する 1 つの提案を読みましたが、これはかなり聞こえます... 正直、大変です! つまり、機能する可能性はありますが、これを行う機能をテナント (技術に精通していない可能性がある) に与えることは、それほど素晴らしいアイデアではないように思えます。管理者の従業員のみに制限できると思います...

2 つのエンティティ Foo と Bar があり、それらの間に多対多の関係があります。

なぜ Foo が多対多の関係に対して「責任がある」のかについての意味論的議論はないとしましょう。しかし、私たちは Foo が関係に対して責任があると勝手に決定します (つまり、NHibernate では Bar を Inverse としてマークします)。

DB の観点からはこれで十分ですが、私のエンティティ API には問題があります。

Foo がこの関係の責任を負うと判断した場合、Bar.AddFoo() メソッドを作成せずに Bar の関連コレクションを更新するにはどうすればよいでしょうか?

このような操作の後にこれらのエンティティを DB からリロードする必要なく、ドメイン モデルの整合性を維持できるはずだと思います。

更新: コメンターに触発されたコードの微調整。

JPA では、o/r マッピングが自動的に行われるため、新しい属性ごとに SQL をコーディングする必要はありません。

私はJSFが初めてなので、JSFに同様の可能性があるかどうか疑問に思っていますか?

対応するエンティティで何かを変更するたびに、jsf データテーブルに新しいコードを追加したくありません。

私のチームと私は現在、Spring2.5.6とSpringWebflow 2.0（JDK 1.4.2）を使用してプロジェクトを開始しています。現在、設計段階にあり、Springの永続コンテキスト/エンティティマネージャー（Hibernateを使用します）がサブフローからコミットできるかどうかを知りたいと思います。

commit属性は、end-stateからのみ使用できます。したがって、次のようなフローがある場合：

親フローが完全に実行される前に、サブフローがそのステップをコミットできるようにする必要があります。うまくいけば、それはできます。

サブフローはコミットできますか？または、webflowはこれを禁止し、真の親フローのみをエンティティマネージャー/永続コンテキストでデータベースにコミットさせますか？

私は最近 Java で働き始め、すべてのゲッターとセッターのワイルドでクレイジーな世界を紹介されました。最初は嫌でしたが、すぐに慣れました。慣れすぎ。

私は最近、クラスの設計について考えることに多くの時間を費やしています。私がやろうとしていることの 1 つは、すべてに対してゲッターとセッターを実行するという罠を回避することです。ただし、私が行う作業の多くは、主にデータ コンテナーであるエンティティを使用するものであり、これらの場合にゲッターとセッターが実際に不適切であるかどうかはわかりません。

パブリック プロパティを使用した簡単な例を次に示します。

プライベート プロパティを使用し、ゲッターとセッターを使用する簡単な例を次に示します。

これらの例では、nameとdescriptionフィールドの両方を変更できる必要があります。

nameゲッター/セッターの例はより明確で、実装の詳細を隠しているように感じdescriptionます。必要に応じて、後でセットで検証することもできます。

ゲッターとセッターが悪であり、アンチパターンであるという議論をいくつか読みましたが、この状況には当てはまらないように感じます。

まだ検討していないオプションがいくつかあるかもしれません。提案をお待ちしています！

ドメイン駆動設計で次のパターンが意味があるかどうか知りたいです。

ドメインレイヤーは、モデルとリポジトリで構成されています。アプリケーション層は、ユーザーインターフェイスから、またはModel-View-Controllerパターンのコントローラーからのクエリを処理するサービスで構成されます。

構造の詳細：

特に、メソッドをPhraseエンティティクラスに移動することは理にかなっていますか？その場合、それはどのように呼ばれますか？

編集：

上記の例は、moffdubからの回答とAdeelAnsariからのコメントの後に変更されています。変更が強調表示されます。

追加されたIPhraseRepository.GetPhrase（phraseId）と、それをどのように含めるかについてお聞きしたいのですが。