0

この質問の OP では、WCF/OData を内部データ アクセス レイヤーとして使用することについて質問しています。

EF/L2S/nHibernate を直接使用する代わりに WCF/OData をアクセス レイヤーとして使用する場合の引数

響き渡る返事は、それをしないようです。私はOPと同様の立場にありますが、元の質問では提起されていない懸念があります。さまざまなプラットフォーム向けに (ネイティブに) 開発しようとしていますが、サーバー側のデータとビジネス ロジックをできるだけ多く維持したいと考えています。だから私は iOS/Android/Web (MVC)/デスクトップ アプリケーションを持っています。現在、ORM データ アクセス レイヤー (LLBLGen Pro) を備えた単一の WinForms アプリケーションがあります。

私は、ほとんどのビジネス/データ アクセス ロジック (おそらくまだ LLBLGen または他の ORM を使用している) を WCF/OData インターフェイスの背後に移動することを想定しています。次に、さまざまなプラットフォーム上のさまざまなクライアントをすべて非常に薄くします (基本的に UI と WCF 呼び出し)。

これもオーバーエンジニアリングですか？もっと簡単な解決策がありませんか？

4

2 に答える 2

1

ODataは標準プロトコルであり、あなたのコンセプトはDRY原則にも準拠しているため、アーキテクチャに問題は見られません。

質問を変えます。各クライアントに同じビジネス ロジックを実装して、バグの可能性を増やし、エラーを 1 か所で集中的に修正する可能性をなくすのはなぜですか。あなたのアイデアにより、セキュリティ層を一度だけ実装できます。

OData はクロスプラットフォームの標準であり、各開発プラットフォーム ( MSDN、OData.org、JayData for JavaScript )用の OData ライブラリを見つけることができます。さらに、OData FunctionImports/Service メソッドとエンティティ レベルのメソッドを使用できるため、クエリが簡素化されます。

于 2013-02-13T09:57:00.970 に答える
0

マルチプラットフォーム開発を実行している場合は、複数のドライバーとORMを使用してデータソースに直接アクセスするよりも、HTTPなどのプラットフォームに依存しない通信プロトコルを選択する方が現実的です。さらに、ODataはRESTプロトコルであるため、クライアント側で多くのことを行う必要はありません。ODataHTTP要求をフォーマットし、HTTP応答を解析できるものなら何でもかまいません。ただし、注意すべき点がいくつかあります。

  1. ODataサーバーはSQLデータベースに代わるものではありません。バッチをサポートしますが、DBトランザクションと同じではありません（ただし、多くの場合、トランザクション操作のモデル化に使用できます）。親子関係をサポートしますが、従来のSQLの意味でのJOINはサポートしません。したがって、ODataエンティティとして公開するものを計画する必要があります。EFモデルをラッピングするWCFデータサービスを使用してODataサーバーを構築するのは簡単すぎます。人々は高レベルのドメインタイプを構築する代わりに低レベルのデータベースコンテンツを公開することが多いため、簡単すぎます。

  2. 今日に関しては、ODataマルチプラットフォームクライアントはまだ開発中ですが、それらは来ています。個人的に取り組んでいることを提案する場合は、Simple.Data ODataアダプター（https://github.com/simplefx/Simple.OData、例についてはWikiページを参照）を参照してください。NuGetパッケージが含まれています。これは.NET4.0のみをサポートするクライアントライブラリですが、その一部は、.NET 4.x、Windows Store、Silverlight 5、Windows Phone 8、AndroidをサポートするポータブルクラスLibrarySimple.OData.Clientとして公開するために抽出されています。およびiOS。実際、Gitリポジトリのwinrtブランチを確認すると、マルチプラットフォームPCLが既に見つかりますが、NuGetではまだ公開されていません。

于 2013-02-09T09:00:01.170 に答える