5

.Net でサイトの 1 つを再構築する予定です。私は多くの記事を読みましたが、プロジェクトをデータ アクセス レイヤー (DAL)、ビジネス ロジック レイヤー (BLL)、およびプレゼンテーション レイヤーに分離するというアイデアが本当に気に入っています (私たちは従来の ASP から来ているので、これは私たちにとって大きなステップです) ）。また、Linq to SQL もとても気に入っています。

Linq to SQL は迅速な開発を目的としているため、Linq to SQL で DAL、BLL、およびプレゼンテーション層を持つことは本当に可能ですか? Linq to SQL を使用すると、DAL は BLL で変更される可能性のあるエンティティまたは linq コードを返しますか? Linq to SQL を使用した DAL と BLL の関係は、コンセンサスのないあいまいなトピックのようです。これは私たちにとって非常に大きなジャンプであるため、何かに飛び込む前に、確実に優れたゲーム プランを用意したいと考えています。

型指定されたデータセットは、これにより適しているように見えますが、Linq で同様のものを取得できる場合は、そのルートに進みます。

nHibernate やその他のサードパーティ ライブラリには近づきません。

4

5 に答える 5

5

私たちはあなたが説明したものを正確に構築しており、それを行うために L2S を使用しています。DAL と BLL の関係は少しあいまいであることに同意しましたが、個別の BLL と個別の DAL があります。すべてのロジックは BLL にあり、すべてのデータの取得/変更は DAL への呼び出し (LINQ 呼び出しを使用) を介して行われます。

私たちのアプリは、型指定されたデータセットを使用しません。オブジェクトを表すエンティティ クラスを作成しました。これの一部を構築するのに数か月を費やした今、私たち (私) がデータセットに戻ることはないと思います。

また、L2Sが「急速な発展を目指している」ことにとらわれることはありません。これは、プロトタイピング ツールのように聞こえます。私たちはそれが産業用の強力なツールであることを発見しています. これは、人々が EF を使用することを望んでいるため、Microsoft が現在それについて言っていることとは反対かもしれません。

ランディ

于 2009-12-29T16:42:25.577 に答える
3

一歩下がって、要件をもう一度確認することをお勧めします。

実際の 3 層 (つまり、異なるマシンへの物理的な展開) が必要ですか、それともアプリケーションの論理的なパーティション分割だけが必要ですか?

私が書いた最初の大きなアプリケーションで、まさにこの間違いを犯しました。私は物理的な 3 層を必要としたことはありません (今後も必要ありません) が、そのようにアプリケーションを設計しました。最も顕著な結果は、Linq2Sql がエンティティの切断された変更追跡をサポートしていないことです。私はこの制限を回避するためにLinq2Sql Entity Baseを使用しましたが、これは Persistence Ignorance の概念にひどく違反しています (後からよくわかるようになりますね)。

実際の n 層に移行することは、アプリケーション アーキテクチャに他にも多くの影響を及ぼします。

メッセージ パッシング、データ転送オブジェクトなどが必要になります。Linq2SQL は適切な ORM であり、LINQ との緊密な統合により独自の可能性が提供されます。他の ORM がここに追いつくにはまだ時間が必要です。NHibernate 3.0 は、ここでのトンネルの終わりの光です。Linq2SQL は、単純なデータ モデルがあり、「テーブルごとのクラス」の方法でマッピングできる場合に最適な ORM です。

切断された変更追跡 (n 層に移行する場合に必要になります) については、他の ORM がより適切にサポートされています。

そして最後に：

(私たちは従来の ASP から来ているので、これは私たちにとって大きな一歩です)

このような状況下では、私は特に注意します。スイッチング技術はしばしば過小評価されています。チームの最も賢いプログラマーでさえ、テクノロジの経験がないため、間違った決定を下すことがあります。それでも、新しい道を歩み、スキルセットを向上させることが重要です。決して失敗しない人は、決して成功しません。

于 2009-12-29T16:46:32.747 に答える
2

L2SはDALだと思います。個別のクラスのL2S+ビジネスロジックは、マージされたDAL + BLLになり、DAL側はL2Sランタイムであり、L2Sで生成されたコード（データコンテキスト、エンティティクラスなど）です。

L2Sで生成された部分、エンティティとデータコンテキストの拡張機能は別のDLLに、追加のビジネスロジックは別のdll / service / etcに含まれるように、これらを簡単に分離できます。ただし、多くの場合、それらを分離する必要はありません。

L2Sを使用するときにDAL+BLLに分離する理由の1つは、将来別のデータアクセステクノロジーに移行することが予想される場合、または複数のデータアクセステクノロジーを使用している可能性がある場合です。L2S固有のものとは別のDALを用意すると、DALの切り替えが簡単になります。そのためにDAL+BLLを分離する場合、L2S DAL-DLLは、エンティティクラス、派生クラスまたはプロジェクションクラス、およびエンティティまたはコレクション（リストなど）を取得するメソッドを公開する必要がありますが、DataContextはDALの内部に保持します。 L2S固有のもの（L2Sクエリなど）がBLLに流れ込むのを避けるためのクラス。

JMHO。

他の人がL2Sツールについて言及したので、ここにそこにあるもののより完全な要約があります：http ://www.thinqlinq.com/post.aspx/title/linq-tools

于 2009-12-30T02:25:58.783 に答える
0

IMHO、LINQ to SQLは、現在利用可能な最良の選択です。これにより、データの操作が簡単になり、ほとんど楽しくなります。:-) LINQ to SQLに興味がある場合は、PLINQOプロジェクトをご覧ください。LINQ to SQLにいくつかの優れた機能拡張があり、全体的なソリューションが改善されています。

于 2009-12-29T23:17:22.127 に答える
0

linq では、DAL と BLL の概念はもはや意味がないと思います。そこで、コード (親) フォルダーの下の「ドメイン」フォルダーの下に、linq クラスといくつかのゲッターとセッターを配置しました。次に、「Repository」クラスと「FontEnd」クラスを作成しました。

于 2010-09-19T17:57:32.927 に答える