ASP.NET サイトで再利用したい WebAPI ODATA サービスがあるため、BreezeSharp の使用を検討し始めました (javascript は関係なく、純粋な C# のみです)。
残念ながら、ドキュメントによると、すべてのモデル エンティティが Breeze.Sharp.BaseEntity を継承する必要があることに気付きました。これは、私たちのビジネス モデルが Breeze に依存することを意味するため、私たちにとってはあり得ません。この依存関係を WebAPI サービスのみに維持したいと考えています。
とにかくこれを避けることができますか？たとえば、 BaseEntity から継承しない場合、クライアント側にプロキシ クラスがありますか?
これについて何か考えはありますか？
私の理解が正しければ、あなたの唯一の懸念は、サーバー モデルでbreeze# ライブラリを参照したくないということです。どうやら、クライアントとサーバーのエンティティ クラスの密接な結合に問題はないようです。それらには同一のプロパティと、おそらく共有メソッドもあるという意味です。私は批判的ではありません。私はあなたのアーキテクチャ上の決定を確認しようとしているだけです。
部分クラスを検討しましたか?
サーバー側のビジネス モデル プロジェクトで簡単な部分クラスを定義し、クライアント モデル プロジェクトでそのクラス ソースにリンクします。クライアント固有の機能を備えたコンパニオン部分クラスを保持します。そのクライアント部分クラス ファイルは、breath# 基本クラスを指定します。
その際、クライアント プロジェクトではなくサーバー プロジェクトに存在する部分クラス ファイルに、サーバーのみのロジックを分離することができます。
このようなソース ファイルのリンクは、Microsoft が"ユニバーサル アプリ"のビジョンで VS を推進しているため、VS を使用するとさらに簡単になりました。
Breeze.Sharp.BaseEntityの要件は純粋にクライアント側にあります。その理由は、永続性、ナビゲーション、キー修正、変更追跡、通知、その他のブリーズ クライアントを使いやすくするサービスをすべて提供するためです。
Breeze.Sharp.BaseEntity が実装するIEntityインターフェイスがあり、Breeze.Sharp.BaseEntity を使用する代わりに自由に実装できますが、これは非常に重要な作業です。私たちのコミュニティが一般的に望ましいと判断した場合は、後日、これに関するガイダンスを提供することを検討しています.
また、POCO モデル オブジェクトの上に直接注入できるIEntityの AOP 実装のリリースも計画していますが、これには PostSharp が必要になる可能性が高く、一部のクライアント プラットフォーム (Xamarin for Android/IOS) での実行に問題が生じる可能性もあります。需要を把握するまで、これに対する時間枠はありません。
一方、現在の実装は、モデル オブジェクトを非常に尊重しています。モデルには、単一の「EntityAspect」プロパティと複数のイベントが追加されています。
過去に、他の多くのプラットフォームやアプリケーション ライブラリで純粋な POCO アプローチを試しましたが、特にこのライブラリを Xamarin を含む任意の .NET クライアントで実行することを考えると、基本クラスの最小コストよりも不利な点の方が大きいことがわかりました。 /単核症。