2

私は現在、嫌いなTelerik Open Accessを使用していますが、一般的にLINQとORMの使用に関するアーキテクチャ上の問題はありませんか?

私たちがやっていることは、データ操作の負担を、そのタスクを実行するように最適化された DBMS から、私の場合はそうではない Web サーバーに移すことです。

また、少なくとも Telerik の場合、コーディング モデルの柔軟性を制限しています。このプロジェクトでは、CRUD インターフェイスに直接マップされない複雑なデータ構造を抽出して作成する必要があります。少なくとも Telerik Open Access では、ストアド プロシージャを使用してデータを作成し、それが既知のエンティティにマップされない場合、データをオブジェクト配列として返す必要があります。

その代わりに、ORM によって作成された「エンティティ」を使用し、LINQ を使用してそれらを操作します。結果として得られるコードは、同等の比較的単純な SQL ステートメントと比較して、途方もなく複雑です。

特に ORM と LINQ を使用することの支持と、これがアーキテクチャ的に不健全であるかどうかについて、あなたの意見に興味があります。

それは確かに私には感じられます。

実際のコードは無関係なので、コード サンプルは含めていません。とはいえ、10 行の T-SQL クエリ (そのうちの 6 行は結合) が 300 行 (空白を含む) の LINQ ステートメントに変わって同じことを行うことを知ることは有益かもしれません。

4

2 に答える 2

3

Linq2SQLまたはLinq2Entitiesを使用する場合、それらは実際にSQLコードを生成し、「データ操作の負担」は引き続きDBMSに残ります。作成するLinqコードは、サイズがSQLコードと非常によく似ています。

于 2012-08-20T10:51:42.967 に答える
1

ORM に加えて Linq を使用することは、アーキテクチャ的に不健全ではありません。

データベース側とクライアント側で常にある程度のデータ操作が行われます。開発者として、適切なバランスを見つけるのはあなた次第です。明らかに、ORM によって、クライアント側で型指定されていないデータの寄せ集めを操作したり、Linq で大規模なクエリを実行したりするなど、複雑なことを行う必要がある場合は、問題があります。ORMまたはシステムの設計方法のいずれかで。

于 2012-08-20T18:28:43.830 に答える