LINQ to SQL - 軽量O/RM？

Question

LINQ to SQLは軽量アプリケーションに適していると聞きました。しかし、私はStackoverflowのために使用されているLINQと、私が知っている他の.comの束（彼らとのインタビューから）を参照してください。

これは本当ですか？何百万もの電子商取引サイトのために、通常は何か複雑なもののために時々格納されたprocを除いて、ほとんどの場合基本的なCRUDを実行しているだけです.LINQ to SQLは十分に完成しており、パフォーマンス上十分です。電子商取引サイトでうまく動くほど十分に微調整されていますか？より良いアプローチのためにLINQ to SQLを使用する場合、DB側のパフォーマンスを調整する必要があると聞きました。 「軽量」O/RMソリューションの

1）意味/範囲/定義：

は、だからここは本当に2つの質問がありいったい「軽量」人々がにLINQを言うときどういう意味しますSQLは "軽量O/RM"であり、それは本当ですか？これはとても軽量の場合、なぜそれを使用して巨大な.comsの束を参照してください？

メジャー.coms（明らかにそれはそうであるように見える）を実行するのに十分であり、「軽量」のコンテキストが何であるかを決めるのはそのような一般的なステートメントです。

2）パフォーマンス：私は自分の.comに取り組んでおり、さまざまなO/RMを研究しています。 Entity Framework（まだ）を見ているわけではなく、ここでLINQ to SQLの基本を理解し、それが十分に効率的かどうかを判断したいだけです。私が考える問題は、生成するSQLを調整したり制御したりすることができないということです。

Answer 1

LINQ to SQLを軽量として記述すると、それは十分に機能していると思いますが、それはやろうとしていないものです。私はこれが良いことだと思う、他のORMがあなたに任せようとする可能性のある余分なものは、ほんの少しの犠牲を払うだけなら、本当に必要なものではないからです。

たとえば、すべてのアプリケーションデータを1つのデータベースに保存することをお勧めします。これは、LINQ to SQLが、結合やその他の操作を実行できるようにするために必要なものです。しかし、いくつかの官僚機構のある環境で作業する場合、レガシーデータを移動させたり、一元的にデータを集中させたりすることを全員に納得させることができないかもしれません。最終的には、より複雑なORMが必要になり、間違いなくクラッパーソフトウェアになります。それは、必要なときにそのデータを整形できないかもしれない理由の1つの例に過ぎません。

巨大な.comが一貫した方法でやりとりを行い、ベストプラクティスに従えば、ORMを必要なだけ簡単にすることはできません。