Within an n-tier app that makes use of a WCF service to interact with the database, what is the best practice way of making use of LinqToSql classes throughout the app?
I've seen it done a couple of different ways but they seemed like they burned a lot of hours creating extra interfaces, message classes, and the like which reduces the benefit you get from not having to write your data access code.
Is there a good way to do it currently? Are we stuck waiting for the Entity Framework?
linq-to-sqlオブジェクトを分散システムの他の部分に渡すことは確かに良い考えではありません。そうすると、クライアントをデータベースの構造に結合することになりますが、これは決して良い考えではありません。ちなみに、これはDataSetsの主要な問題の1つでした。
データオブジェクトを転送するための独自のクラスを作成することをお勧めします。もちろん、これらのクラスはDataContractsとして実装されます。サービスレイヤーでは、linq-to-sqlオブジェクトとデータキャリアオブジェクトのインスタンスの間で変換します。面倒ですが、サービスのクライアントをデータベーススキーマから切り離します。また、システムで渡されるデータをより適切に制御できるという利点もあります。
LINQ to SQL は、分散アプリでの使用にはあまり適していません。変更の追跡と遅延読み込みは、データベースに関連付けられている DataContext の一部であるため、ネットワークを介して移動することはできません。L2S エンティティをネットワーク上で移動、変更、元に戻し、DataContext に再アタッチしてデータベースを更新できますが、これにはかなり制限があり、古い値が保持されないため、すべての同時実行チェックが失われます。
ところで、L2Eにも同じことが当てはまると思います。