4

私はODataを見ていますが、それは非常に強力であると同時に、非常に当惑させられます。これは、データソースをリモートユーザーに公開するのと同じです。灘のサービスはなく、注入ポイントもほとんどないため、ほぼコミカルな2層アーキテクチャになります。

私の懸念は次のとおりです。

  1. ODataを使用している間は、DDDなどのパターンを適用するのは困難です。

  2. また、SOAデータ転送オブジェクトのセットに対してODataを使用することも困難です。これらは通常、クエリ可能ではないためです。つまり、DTOを取得するまでに、DBクエリは実行されますが、ODataは起動したばかりです。DTOはすでにメモリ内にあるため、クエリを実行してもそれほど価値はありません。

  3. ODataエンティティの表現であるDB自体にビューを作成できますが、これによりUIの問題が永続化されます。ビッグノーノー。

  4. せいぜい、さまざまなDDDサービスからの結果セットを組み合わせるのは、kludgy javasciptを使用してUIレイヤーで行われるようになりました。これは、再利用性の記録が不十分なメンテナンスの悪夢です。

  5. もう1つの可能性は、ViewModelレベルのクラスである可能性が高いODataエンティティのトランスレータを作成し、それをDTOに変換し、次にドメインに変換し、次にConceptualModelsに変換し、残りはORMが処理できるようにすることです。しかし、これには膨大な量のリソースが必要になります。

つまり、ODataをSOA、オブジェクト指向カプセル化の原則、DDD、そして古き良きSOCとどのようにうまく連携させるのでしょうか。

4

1 に答える 1

3

OData標準とOData実装を明確に分離する必要があります。

標準について：

私の見解では、標準自体により、移植可能な方法で完全なメタデータを備えたOOTBアクセス可能なデータエンドポイントを使用できます。リレーションとプロジェクションのサポートにより、コンシューマーはサーバー上または後でクライアント上でビューモデルを作成できます。ODataは公開される操作（関数）をサポートしているため、自動クラッドに加えて、リレーショナルパターンにシームレスに統合するリモートメソッドを使用できることに注意してください（関数は、さらにクエリできる結果を得ることができます。サーバー、および関数は「スマートライター」コードとして機能することもできます）。

まとめ：ODataは、誰かが大規模なREST準拠のデータアクセスを必要とするときに実際に何が起こるかを形作ります。データのクエリやデータの送信など、一般的で常に繰り返されるシナリオを形式化します。これは、ポイント4で書いた内容によって影響を受ける可能性がありますが、私の意見では、OData関連の問題ではありません。これは、AJAXとマッシュアップがどのように機能するかを示しています。データの結合を処理する多くのコードを持つクライアントがあります。

あなたの他の問題は、最も適切なサーバー実装を選択することで答えることができます。すでにいくつかの実装があります：

  • EF4 / EF5+WCFデータサービスが最も「自動」です。このユースケースでは、懸念事項のいくつかについては正しいかもしれませんが、EFの優れた拡張性モデルを使用すると、必要に応じて自動操作を操作できます。実際のEDMXモデルによって駆動されるアプリケーションを持つことは、真のDDDシナリオです。

  • ASP.NET Web APIを使用すると、静的なリレーショナルエンドポイントとして認識されるものに対して、完全にコードベースのバックエンドを使用できます。これにより、DB、DBデータ間を橋渡しする中間層、およびクライアントに最適であり、そのモデルのスマートコンシューマーとしてのクライアント層。

  • JayDataは、これらをサーバーサイドJavaScriptで提供し、JavaScriptのダイナミズムを追加します。

  • SAP NetWeaverゲートウェイは、単純なシナリオで簡単に利用できる方法で複雑なSAPデータを公開します。

OOの懸念：ODataのV3では、「インスタンスメソッド」（これは間違いなくサーバーメソッドでもあります）があるため、SOAがデータと機能に残酷に分離することで実際に取り除いたものは、機能の定義+カプセル化されたデータにマッピングされます。のように機能するコンテキストデータを使用する静的メソッドのSOAの概念"this"。

2Tierの懸念：IMHO 2Tierアーキテクチャは、クライアントがサーバー側の構造についてあまりにも多くの知識を持っているためではなく、拡張性が低く、新しいシンクリエンテスが実際のDBクライアントのように機能するために愚かだったために「古代」になりました。実際、2層は（開発者の観点から）常に操作が簡単でした。実際、ODataサーバーの実装は実際にロジックを備えた中間層であるため、実際には両方の長所を活用できます。-仮想2層アーキテクチャに対するコード-通常のn層アプリケーションと同じように拡張できます。

于 2012-10-25T08:58:22.153 に答える