1

クライアント/サーバー アプリケーションがあり、クライアントとサーバーにはいくつかの共通テーブルがあります (アプリケーションの一部として同期がとられています)。

現在、これらのテーブル (つまり FileDetails) を Shared.dbml ファイルに保存しています。これまで、一連の FileDetails の結果を返すストアド プロシージャはすべて、(サーバーのみの) SP であっても Shared.dbml に配置されていました。

私は、LINQ to SQL が DBML のベース クラス プロパティをサポートしていることを発表しました。おそらく、Shared.dbml を拡張する Server.dbml を作成できるのではないかと考えました。理論的には、これにより、すべての共有テーブルと SP、およびサーバー固有の要素を含む ServerDataContext が得られます。通常、SQL デザイナーでは、SP を FileDetails テーブルにドラッグ アンド ドロップして、これが返されたことを示しますが、クラスが別の DBML にあるため、これは不可能であり、XML では ElementType は考えられません。 IdRef="1" アプローチが機能します (参照が別のファイルを指す必要があるため)

XML の戻り値の型を手動で編集することで、この問題を回避できることがわかりました。

<Function Name="dbo.SELECT_FTS_FILES" Method="SELECT_FTS_FILES">
    <Return Type="ISingleResult&lt;DataTypes.FileDetails&gt;" />
</Function>

私の質問は、この種のアプローチの経験があり、さらにリソースを教えてくれる人はいますか? 明らかな欠点はありますか (手動の XML 更新以外に)

すべてのフィードバックを歓迎

4

1 に答える 1

2

データコンテキストから継承できます。ただし、新しいデータコンテキストでは、linq デザイナーを使用できず、手動でコーディングする必要があります。

2 つのデータコンテキストが不要な理由はありますか?

一般に、継承と LinqToSql はうまく連携しません。それが本当に必要な場合は、NHibernate のような別の ORM を調べる必要があります。

于 2009-05-21T12:41:54.113 に答える