c# - LINQ To SQL の使用を開始する必要がありますか?

Question

現在、NetTiers を使用して、データアクセスレイヤーとサービスレイヤーを生成しています。私は NetTiers を 2 年以上使用しており、非常に便利であることがわかりました。ある時点でLINQを見る必要があるので、質問は...

NetTiers から LINQ To SQL に移行した人はいますか?
この切り替えは良いことでしたか、それとも悪いことでしたか?
知っておくべきことはありますか？
このスイッチをお勧めしますか？

基本的にどんな考えでも歓迎します。

score 5 · Accepted Answer

いいえ
＃1を参照してください
標準的な抽象化のオーバーヘッドに注意する必要があります。また、現在の状態では非常に SQL Server ベースです。
SQL Server を使用していますか。現在、XML データ (素晴らしい)、オブジェクトデータ、データセットなど、他の目的で LINQ を使用している場合は、それらすべてに対して統一されたデータ構文を使用するように切り替える必要があります。ラガーダレクが言ったように、壊れていない場合は修正しないでください。.netTiers Application Framework を簡単に見てみると、そのソリューションに既に投資している場合は、単純なデータアクセスレイヤー以上のものが得られるように思われるので、それを使い続ける必要があります。

私の経験から、LINQ to SQL は中小規模のプロジェクトに適したソリューションです。これは、生産性を向上させる優れた方法である ORM です。また、別の抽象化レイヤーを提供して、下のレイヤーを別のものに変更できるようにする必要があります。Visual Studio のデザイナー (そして私は VS Express もそうだと思います) は非常に簡単で使いやすいものです。これにより、オブジェクトマッピングの一般的なドラッグアンドドロップおよびプロパティベースの編集が可能になります。

@ Jason Jackson - デザイナーではプロパティを手動で追加できますが、そのプロパティの属性を指定する必要がありますが、これを一度行うと、最初にテーブルをデザイナーにドラッグするよりも 3 分長くかかる場合があります。データベース自体の変更ごとに 1 回だけ必要です。これは他の ORM とそれほど違いはありませんが、これをはるかに簡単にし、変更されたプロパティのみを見つけたり、そのようなニーズに合わせて何らかのリファクタリングツールを実装したりすることができることは間違いありません。

資力：

Parallel LINQは、マルチコアマシンでより優れたパフォーマンスを実現するために開発されていることに注意してください。

score 2 · Accepted Answer

小さなプロジェクトでLinqtoSQLを使用してみましたが、すぐに生成できるものが必要だと思いました。私はデザイナーで多くの問題に遭遇しました。たとえば、テーブルに列を追加する必要があるときはいつでも、基本的にデザイナでテーブル定義を削除して再度追加する必要があります。テーブルにプロパティを設定した場合は、それらのプロパティを再設定する必要があります。私にとって、これは開発プロセスを本当に遅くしました。

LINQtoSQL自体は素晴らしいです。私は拡張性が本当に好きです。彼らがデザイナーを改善することができれば、私はそれをもう一度試すかもしれません。フレームワークは、Web開発のような切り離されたモデルを対象としたもう少し多くの機能の恩恵を受けると思います。

使用方法の優れた例については、 ScottGuthrieのLINQtoSQLシリーズのブログ投稿を確認してください。

score 1 · Accepted Answer

NetTiers は、重くて堅牢な DAL を生成するのに非常に優れており、内部でコアライブラリとフレームワークに使用しています。

私が見ているように、LINQ (すべての化身ですが、具体的には SQL を求めていると思います) は、迅速なデータアクセスに優れており、通常、よりアジャイルなケースに使用されます。

どちらのテクノロジーも、コードまたは dbml レイヤーを再生成しないと変更できない柔軟性がありません。

そうは言っても、適切に使用されたLINQ 2 SQLは非常に堅牢なソリューションであり、使いやすいため、将来の開発に使用することもできますが、現在のDALを破棄することはありません-それが壊れていない場合. ..

score 0 · Accepted Answer

私たちのチームは NetTiers を使用していましたが、これが便利であることがわかりました。しかし... 使用すればするほど、頭痛の種や問題点が見つかりました。たとえば、データベースに変更を加えるたびに、以下を含む CodeSmith で DAL を再生成する必要があります。

3 つの別々のプロジェクトで数千行のコードを再生成する
何百ものストアドプロシージャを再生成する

他の方法もあるかもしれませんが、これが私たちがしなければならなかったことです。ソースコードの再生成は大丈夫でした。怖かったですが、大丈夫でした。本当の問題は、ストアドプロシージャにありました。未使用のストアドプロシージャは削除されませんでした。そのため、スキーマからテーブルを削除して DAL を再生成しても、そのテーブルのストアドプロシージャは削除されませんでした。また、これは、古いデータベース構造を新しいデータベース構造と比較し、クライアントインストールを更新するための変更スクリプトを作成しなければならないデータベース変更スクリプトにとって、かなりの頭痛の種になりました。このスクリプトは、数万行の SQL コードに実行される可能性があり、実行時に問題が発生した場合 (常に発生する問題でした)、それを解決するのは非常に困難でした。

その後、ORM としての Hibernate に光が当たりました。確かに立ち上げには時間がかかりますが、それだけの価値があります。それにはたくさんのサポートがあるので、あなたがしなければならないことがあれば、それは以前に行われている可能性が高い. それは非常に柔軟で、そのすべての側面を制御することができます。また、使いやすく、使いやすくなっています。Fluent Nhibernate は、必要な xml マッピングファイルを取り除く優れた方法として登場し、NHibernate Profiler は、効率を高め、冗長性を取り除くために、舞台裏で何が起こっているかを確認するための優れたインターフェイスを提供します。

NetTiers から NHibernate への移行は苦痛でしたが、良い意味でです。これにより、より優れたアーキテクチャに移行し、機能上のニーズを再評価する必要が生じました。NetTiers は大量のデータアクセスコードを提供し、ID でこのエンティティを取得し、外部キーでこの他のエンティティを取得し、あれこれの tlist と vlist を取得しましたが、そのほとんどは不要で未使用でした。ジェネリックリポジトリとカスタムリポジトリを備えた NHibernate は、未使用のコードを大幅に削減し、読みやすさと信頼性を大幅に向上させました。

score 0 · Accepted Answer

現在、かなり大きなプロジェクト (約 150 テーブル) で LINQ to SQL を使用していますが、非常にうまく機能しています。私が最後に使用した ORM は IBatis で、うまく機能しましたが、マッピングを完了するには多くの手間がかかりました。LINQ to SQL は私にとって非常にうまく機能し、これまでのところ、すぐに使用できることが非常に簡単であることが証明されています。移行中に克服しなければならない違いがいくつかあることは間違いありませんが、使用することをお勧めします。

補足として、私は NetTiers を使用したり読んだりしたことがないので、その有効性を軽視するつもりはありませんが、一般的に LINQ to SQL は非常に実行可能な ORM であることが証明されています。

score 0 · Accepted Answer

私の経験では、linq を使用すると処理が速くなりますが、データベースに対する実際のアクションは遅くなります。

だから...小さなデータベースを持っているなら、私はそれに行くと言います。そうでない場合は、変更する前にいくつかの改善を待ちます

c# - LINQ To SQL の使用を開始する必要がありますか?

6 に答える 6

Related

Reference