1


0

asp.netのLINQの問題

データテーブルから必要なデータをフィルタリングするために、LINQ IN ASP.NETを実装したいと思います。 私は正しい場所が何であるか疑っています。 次のオプションがあります

  1. プレゼンテーション層* .aspx.cs

  2. ビジネスレイヤー。

  3. データベースレイヤーで、データベースのクエリが発生します データテーブルとしてビジネス層に戻ります。 次に、ビジネスレイヤーは結果をプレゼンテーションレイヤーに返します。

誰でも私がLINQの正しい場所を見つけるのを手伝ってくれますか?ユーザーセレクタフィルターごとにデータテーブルからデータをさらにフィルタリングする必要があるためです。

助けてください?

4 Answer


3


Linqはすべてのレイヤーで使用できますが、この種の操作を行うのに最適な場所はビジネスレイヤーです。 これにより、コードをより保守しやすくなり、他のページで将来使用するために簡単に共有できます。


1


linqを使用してデータをフィルタリングするだけの場合(たとえば、linq to objects、linq to datasets)-ビジネスレイヤーで使用できます。

linq to sqlを実行してデータ操作を実行している場合は、データアクセスレイヤーを使用できます。 ただし、アプリが小さすぎる場合は、任意のレイヤーで使用できます。


0


代わりにASP .NET MVCフレームワークを試してみませんか? ASP .NETの上に構築されているため(すべての機能を活用できます)、レイヤーを適切に配置し、懸念事項をかなり適切に分離できます。 他の人が答えたように、理論的には最善のオプションはビジネス層にコードを配置することです。 これは、ASP .NET MVC構造のモデル部分です。

それを試してみると、あなたの答えは自然に発生します。


0


ヘマント、あなたの重要な声明は、「ユーザーセレクターフィルターごとに、データテーブルからデータをさらにフィルター処理する必要があります」と思います。最初のデータ選択は、明らかにビジネスレイヤーからA)データベースをUIから分離し、B)ビジネス固有のルールを実装してデータをUIに配信する前に「調整」する必要があります。

ユーザーインタラクションに基づいてサブセットを選択しているだけなので、UIにロジックを配置することは完全に合理的だと思います。 実際、これは、UIでデータ中心の操作を実行するのが理にかなっている_only_条件である可能性があります。

そうは言っても、ビジネスロジックレイヤーの特別なクラスにユーザーベースのフィルターを実装しました。 すべてのユーザーフィルタリングが特定の焦点を持っている(データベース全体に及ぶわけではない)ので、これは私にとって理にかなっています。

だから-ここにあなたの選択があります。 実際にユーザーフィルターを実装しているだけで、表示するデータに基づいてさまざまなページに異なる種類のフィルターがある場合、UIレイヤーにフィルターロジック(のみ)を配置するための合理的な引数があります。 結局、UI相互作用コードを実装することになります! ただし、すべてのページが使用する別のクラスでユーザーが要求できるフィルターの範囲をカプセル化するクリーンな方法があれば、そのクラスをビジネスロジックレイヤーに配置することを推奨します。