現在、私はデータアクセス層とサービス層を生成するためにNetTiersを使用しています。私はNetTiersを2年以上使っており、非常に有用であることが分かっています。ある時点で私はLINQを見なければならないので、私の質問は...LINQ To SQLの使用を開始する必要がありますか？
基本的に私はどんな考えも歓迎します 。
私の経験から、LINQ to SQLは、中小規模のプロジェクトに適したソリューションです。これはORMであり、生産性を向上させるのに最適です。また、はとなり、別のレイヤを抽象化することで、その下にあるレイヤーを変更することができます。 Visual Studioのデザイナー（そしてVS Expressも同様です）はとても簡単で使いやすいです。これは、オブジェクトのマッピングの一般的なドラッグドロップとプロパティベースの編集を提供します。
@Jason Jackson - デザイナーでは、プロパティを手動で追加することができますが、そのプロパティの属性を指定する必要がありますが、これを1回実行すると、デザイナーに最初にドラッグされる時間ただし、データベース自体の変更につき1回だけ必要です。これは他のORMとあまり違いはありませんが、これをはるかに簡単にすることができ、変更されたプロパティのみを検索したり、そのようなニーズに対して何らかのリファクタリングツールを実装することもできます。
資源：
Parallel LINQは、マルチコアマシンではるかに優れたパフォーマンスを実現するために開発されています。
NetTiersは重く堅牢なDALを生成するのに非常に優れており、コアライブラリとフレームワークに内部的に使用しています。
LINQ（すべてのインカネーションで、具体的には私がSQLに依頼していると思う）は素早くデータにアクセスすることができ、一般的にはより機敏なケースに使用します。
どちらのテクノロジも、コードやdbmlレイヤを再生成することなく変更するのは非常に柔軟性がありません。
LINQ 2 SQLは非常に堅牢なソリューションであり、使いやすさのために将来の開発に使用することもできますが、現在のDALを捨てることはありません。それは壊れていません...
私の経験から、linqを使用するとより速く作業を進めることができますが、データベースに対する実際のアクションは遅くなります。
小さなデータベースをお持ちの場合は、私はそれを求めて言います。そうでない場合は、変更する前にいくつかの改善を待つことになります
小さなプロジェクトでLinqをSQLに使用しようとしました。私はデザイナーの多くの問題に遭遇しました。たとえば、テーブルに列を追加する必要がある場合は、基本的にデザイナのテーブル定義を削除して再追加する必要があります。テーブルにプロパティを設定した場合、それらのプロパティを再設定する必要があります。私にとってこれは開発プロセスを本当に減速させました。
LINQ to SQL自体は素晴らしいです。私は本当に拡張性が好きです。彼らがデザイナーを改善できたら、私はもう一度それを試してみるかもしれない。私は、フレームワークは、Web開発のような非接続モデルを対象としたもう少しの機能性の恩恵を受けると考えています。
ブログ投稿のScott Guthrie's LINQ to SQL seriesをご覧ください。
パーシャルクラスを使用してLINQからSQLに生成されたソースファイルを変更し、デザイナで生成されたソースを更新できる方法を示す素晴らしいサイトです。 http://dotnetslackers.com/articles/csharp/Making-LINQ-to-SQL-A-Bit-More-Abstract.aspx –
かなり大きなプロジェクト（約150テーブル）でLINQ to SQLを使用していますが、これは私のために非常にうまく機能しています。私が使用した最後のORMはIBatisでしたが、うまくいきましたが、あなたのマッピングを完了させるために足を踏み入れました。 LINQ to SQLは私にとって非常によく機能し、これまでのところ非常に使い易いことが証明されています。移行時に克服しなければならない違いがありますが、その使用をお勧めします。
NetTierを使用したり読んだことは一度もありませんでしたので、効果はそれほど重視しませんが、LINQ to SQLは一般に非常に実行可能なORMであることが証明されています。
私たちのチームはNetTierを使用していましたが、これは有用であるとわかりました。しかし、私たちがそれを使用するほど、頭痛や痛みのある箇所が増えました。
多分、他の方法がありますが、これは私たちがしなければならないことです。ソースコードの再作成はOK、恐ろしいですが、大丈夫でした。実際の問題はストアドプロシージャで発生しました。使用されていないストアドプロシージャは削除されませんでした。そのため、スキーマからテーブルを削除してDALを再生成した場合、そのテーブルのストアドプロシージャは削除されませんでした。また、これは、古いデータベース構造を新しいデータベース構造と比較して、クライアントインストールを更新するための変更スクリプトを作成する必要があったデータベース変更スクリプトの頭痛になりました。このスクリプトは何万行ものSQLコードに実行される可能性があり、実行中の問題があった場合は常にそれが解決されていました。
そして、光が来て、NHibernateがORMとして来ました。それは確かにそれにランプアップ時間がありますが、それは十分な価値があります。それにはたくさんのサポートがあります。あなたが何か必要なことがあれば、これまで以上に多くのことが行われています。それは非常に柔軟性があり、あなたはそれのすべての側面を制御することができます。また、使いやすくなっています。 Fluent Nhibernateは、必要とされているXMLマッピングファイルを取り除くための優れた方法です。NHibernate Profilerは、効率を高め冗長性を取り除くために何が起こっているのかを見るための優れたインタフェースを提供します。
NetTiersからNHibernateへの移行は苦労しましたが、良い方法です。これにより、私たちはより良いアーキテクチャに移行し、機能的なニーズを再評価しなければなりませんでした。 NetTierは、大量のデータアクセスコードを提供し、そのIDでこのエンティティを取得し、その外部キーによってこの他のエンティティを取得し、これとtlistとvlistを取得しますが、そのほとんどは不要で未使用でした。ジェネリックリポジトリとカスタムリポジトリを必要とする場合にのみ、NHibernateは未使用コードの量を減らし、本当に可読性と信頼性を向上させました。
netTiersを使用すると、ストアドプロシージャではなくパラメタ化されたSQLを使用するように設定できます。これはdbのsp混乱からあなたを救う。 –
こんにちは、 次のバージョンの.netTiers（v3.0）では、これらのオーバーヘッドと苦労ポイントを削除/削減するよう取り組んでいます。 ありがとうございました -Blake Niemyjski –
「データベースへの実際のアクションが遅い」という経験はどうでしたか？あなたはあなたが行ったパフォーマンステストの説明を書いて、人々があなたがそれを作り上げているだけではないことを知るようにすべきです。 – liammclennan