0

重複の可能性:
Linq To SQL をコード ビハインドで直接使用するか、他のアプローチを使用する必要がありますか?

コードビハインドからのLinqクエリの分離の前に、すでに質問しました。

探している答えが得られなかったのかもしれません。それで、もう一度質問します。直接クエリを実行するために mylinqを使用します。私は関数を使用します。Sqlcode behind

私の質問は、それらをどのように分離すればよいcode behindですか?

より良いアプローチは何ですか。シンプルを使用してそこで操作classesを実行し、コードビハインドからそれらの関数を呼び出すだけでよいでしょうか。database(querying,insert,update,delete)

それは私が従うべきアプローチですか？はいの場合、単一のクラスを使用するか、ページごとに 1 つのクラスを作成する必要があります。

これをどのように整理すればよいか、誰か教えてもらえますか?

を使用してASP.NET Web Forms/C#います。

簡単な例が大きな助けになります。

どんな提案でも大歓迎です。

4

2 に答える 2

1

データ アクセス レイヤー、ビジネス レイヤー、およびプレゼンテーション レイヤーを持つ N 層アプローチを選択することもできます。データ アクセス レイヤーには LINQ to SQL が含まれ、ビジネス レイヤーはデータ アクセス レイヤーとプレゼンテーション (UI) レイヤーの間のブリッジとして機能する必要があります。

次の記事を見てください: Using LINQ to SQL in N-Tier Architectures

于 2012-07-02T05:38:02.347 に答える
1

いくつかの点で、LINQ クエリは実際には 'SQL' クエリと見なされるべきではありません。たとえLINQ2SQL後で EF プロバイダーに渡されたとしてもです。LINQ 式は、間違いなくクエリ基準パターンの柔軟な実装と見なすことができます。たとえば、Evan の仕様パターンと同様に、返される「何」を指定し、理想的にはこれを行うための「方法」に関する SQL 仕様を最小限に保ちます。

DataContextとはいえ、またはIQueryableをプレゼンテーション層に直接公開すると、システムのテストが難しくなる可能性があります。通常、LINQ 式を専用の「データ層」に制限することを検討することをお勧めします。

編集

同様の議論がここにあります: http://social.msdn.microsoft.com/Forums/en-NZ/linqtosql/thread/2df752fd-6a1d-441b-b7c4-ecf1a7a00161

具体的には、Linq2SQL の一般的なリポジトリ パターンが http://multitierlinqtosql.codeplex.com/にあります。

ただし、Linq2SQL で高度に階層化されたアーキテクチャを実装する前に、Linq2SQL を Entity Framework 4+ に置き換えることを再検討することができます。DataContextsたとえば、L2SQL の問題は、エンティティがコンテキストにバインドされていることです。つまり、エンティティを使用する必要があるレイヤーを持ち運ぶことへの依存を断ち切りたい場合は、単純なデータ エンティティ (POCO) をマップする必要があります。IMO Linq2SQL は、抽象化をあまり必要としない小規模なプロジェクトに最適です。

于 2012-07-02T05:47:38.360 に答える