1

かなり大きな DBML ファイルがあり、最近、Visual Studio の MSLinqToSQLGenerator が以下とは異なる出力を生成していることを発見しました。

SqlMetal.exe All.dbml /code:All.designer.vb /namespace:LINQ2FSE /pluralize /provider:SQL2005

生成された VB コードから任意の (そして比較的小さいと思う) 関連のセットを削除したようです。しかし、SQLMetal は問題なく動作します。出力は同じであるべきではありませんか？

さらに調査した結果、違いは、列の数が異なる同じエンティティの他のアソシエーションでも使用されるプロパティを含むエンティティのアソシエーションであるように思われることがわかりました。例: エンティティ A には列 id と name があります エンティティ B には列 id、name および fkA (A への外部キー) があります エンティティ C には列 id、name、fkA および fkB (nullable fkB) があります

エンティティ C には、fkA を A.id にリンクするアソシエーション C_A があり、fkA と fkB を B.fkA と B.id にリンクするアソシエーション C_B もあります。

C_B をサポートするプロパティのコードは、Visual Studio では生成されませんが、SqlMetal.exe によって生成されます。

このような協会は許されますか？コードが異なる方法で生成されている理由はありますか?

4

1 に答える 1

2

SQLMetal が IDE の MSLinqToSQLGenerator とは異なる出力を生成することが (Microsoft の助けを借りて) 判明しました。DBML ファイル (私が作成したツールによって生成された) には、親が子にアクセスできるいくつかの関係が定義されていましたが、子は親会。どうやら、子から親への関連付け (外部キー関係) を定義する必要があるようです。親から子への関連付けのみが定義されていて、逆関連付けが定義されていない場合 (または逆関連付けの名前が異なる場合)、その関連付けの .NET ソース コードはどちらの方向にも生成されません。これは MSLinqToSQLGenerator では正しく処理されますが、SQLMetal ではそれほど多くの検証が行われず、とにかく関連付けコードが生成されます。

于 2009-09-07T18:32:08.777 に答える