6

私は linq2sql と linq DTO (linq2sql によって作成されたクラス) の操作に成功しています ....

私は混乱しています。古いアプリケーションを更新するタスクがあり、DTO が本来あるべき方法で使用されることがわかります....日付を転送する

私はリポジトリ パターンを使用しているので、linq2sql dtos を介してリポジトリからサービスにデータを渡しています...サービス層に入ったら (これは基本的に私のビジネス ロジックです)、クラス オブジェクトを渡す必要があります。

これらのクラス オブジェクトは、基本的に dtos のミラー イメージ (多かれ少なかれ) です。いくつかの場所でいくつかの変更がありますが、一般的には同じです..

ということで、本題に戻ります！-- リポジトリからサービス層にデータを転送するためだけに dtos を使用するのは、この良い方法ですか...そしてサービス層 (ビジネス ロジック) に入ったら、すべての dtos をクラス オブジェクト カウンター パーツにマッピングする必要があります (もちろん automapper を使用して! !)

私の他の代替手段は、クラスオブジェクトのようなDTOSを引き続き使用し、メソッドからメソッドへ、および戻り値の型などとして渡すことですが、これは悪い習慣だと感じており、どのメソッドを適用すべきか疑問に思っていますか?

どんな助けでも本当に感謝しています

ありがとう

4

4 に答える 4

5

ここに私の意見があります：自明ではないアプリケーションを扱うとき。ドメイン モデルとして linq2Sql オブジェクトを使用することは、非常に悪い考えです。linq2Sql は ORM であり、それ以上のものではありません。データベース (linq2Sql が直接対応している) は、dataの正規化です。クラス (OOAD の意味で) は、 (データではなく)動作の正規化です。

[これらのクラス オブジェクトは基本的にミラー イメージです]...

linq2Sql でアプリケーションを構築しているときに、これに遭遇しました。現実的に考えてみましょう....ほとんどの基幹業務アプリケーションは、美化された CRUD アプリケーションです。したがって、アプリケーションのエンティティの大部分がデータベース テーブルに直接対応することは問題外ではありません。 生成された DTO に直接バインドされたくはありませんでしたが、同時に、重複したクラスがアプリケーション全体に散らばりたくありませんでした。

だからここに私の解決策があります：
私は「インターフェースにプログラムしました」。

（データベース列に直接関連する）の​​プロパティを持つ（Data PersonDtoTransfer Objectを表すDto）があるとしましょう。FirstName, LastName, Age

IPersonインターフェイスを作成し、PersonD にそれを実装させました。


  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

また、私のリポジトリ メソッドはIPerson、Linq2Sql クラスとは対照的に、取り込みと取得を行います。


    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

このアプローチは、私にとって非常にうまく機能しました。DTO から逸脱する必要があると感じたときはいつでも、DTO ではなくオブジェクトを表すインターフェイスのおかげで、かなり簡単に逸脱することができます。

いくつかの一般的なヒント: DTO を手動で作成する...おかしなことに聞こえるかもしれませんが、トップダウンのテスト駆動型開発アプローチでうまく機能することがわかります。DTO の (linq2Sql) オブジェクトは非常に軽量で、.dbml デザイナーの外部で変更できるようになります。

DTO と DataContext を内部に保持します。dto を公に公開する理由はありません (リポジトリとドメイン オブジェクトのパブリック インターフェイスがある場合)。これを行うと、ドメイン モデルとデータ アクセスが論理的に分離されます。

すべてのデータ アクセス レイヤーを別のプロジェクトに配置します (この分離を強制するため)。

インターフェイス宣言を別のプロジェクトに配置します (これにより、循環参照が発生しないようになります)。

お役に立てれば...

于 2009-08-24T17:49:09.373 に答える
3

私の意図は少し異なっていましたが、私は実際にこのトピックについて同様の質問をしました。推奨事項は、Linq2SQLクラスをドメインオブジェクトとして使用し、他の人が述べているように部分的なクラスを利用することでした。私の主な関心事は、それらのオブジェクトの形状（つまり、プロパティ名）と、クラスメンバーのアクセス可能性（つまり、プライベートとプロテクトなど）にありました。

オブジェクトの形状やアクセシビリティさえも、Damien GuardがT4テンプレートをまとめたt4テンプレートを使用して対処できるため、Linq2Sqlが生成するクラスの形状を制御できます。これは、Linq2SQLのT4テンプレートで確認できます。

これは、私が調査して、それが私の懸念に対処するかどうかを確認するアプローチです。さらに、サービスレイヤーがメソッド引数へのインターフェイスを受け入れることができる場合は、Linq2SQLDTOのインターフェイスラッパーを介してサービスレイヤーがアクセスできるものを制御することもできます。

お役に立てれば。

于 2009-08-24T17:26:10.450 に答える
2

これは、私が見たトピックに関する最高の議論の 1 つです。

http://blog.wekeroad.com/blog/linqtosql-momma-said-knock-you-out/

最終的に、カップリングと結束の決定は状況に応じて決定されるため、状況に最適なものを決定する必要があります。

あなたのアプリケーションが LinqToSql より大きくなった場合、LinqToSql を削除して別の ORM を挿入するのはどれほど簡単でしょうか? それはあなたが真剣に考えなければならないことです。

一般に、ビジネス層が LinqToSql について持っている知識を最小限に抑えます。LinqToSql は UI レイヤーから完全に隠されている必要があります (ビジネス レイヤーはこのシールドのかなりの部分を占めています)。LinqToSql を使用すると、間違ったアーキテクチャ パスをたどってしまうのは非常に簡単であり、事後に正しいパスに戻るのは非常に困難になる可能性があります。

于 2009-08-24T15:55:59.643 に答える
0

linq2sqlデザイナによって生成されるクラスは部分クラスであるため、これらを拡張して、ビジネスロジックを直接それらに配置できます。アイデアは、linqを使用してこれらのエンティティを永続化/再構築するため、話している種類のマッピングを回避できるということです。

于 2009-08-24T15:59:44.583 に答える