4

best practice特定のケースがあり、それを処理する方法を知りたいです。

特定の .NET フレームワーク (Web アプリケーション) を作成します。この Web アプリケーションは、次の方法によって、他の多くの Web アプリケーションに対するプラットフォームまたはフレームワークのように機能します。

依存する Web アプリケーション (プロジェクト ビジネスのクラス、rdlc レポート) を別のソリューションで作成し、それらをビルドします。

その後、結果の dll への参照をフレームワークに追加します。

そして、一連のユーザー コントロール (依存する Web アプリケーションごとに 1 つ) を作成し、フレームワーク自体のフォルダーに配置します。

それは正常に動作しますが、特定のユーザー コントロールに対する変更、または依存する Web アプリケーションのいずれかに対する変更です。参照を再度追加して、フレームワーク全体を公開する必要があります!!

私がやりたいことは、これらのさまざまな Web アプリケーションとフレームワークを疎結合にすることです。そのため、フレームワークを 1 つだけ公開することができ、ユーザー コントロールまたはさまざまな Web アプリケーションに対する変更は、フレームワーク全体ではなく、更新された部分を公開するだけです。

これを実行できるようにコードをリファクタリングするにはどうすればよいですか?

最も重要なことは次のとおりです。

依存するアプリケーションの変更がこのアプリケーションに属する場合は、フレームワーク全体を公開しないでください。更新された部分を公開するだけです。

4

3 に答える 3

4

疎結合が目的の場合は、「フレームワーク (Web アプリケーション)」を開発して、WCF Web サービスとして機能させます。クライアント アプリケーションは要求を Web サービスに渡し、事前定義されたオブジェクトの形式で標準応答を受け取ります。

この方法をとる場合は、追加の手順を実装することをお勧めします。クライアント アプリケーションに渡されたオブジェクトをクライアント コードで直接使用しないでください。代わりに、これらの Web サービス オブジェクトのバージョンを各クライアント アプリケーションに対してローカルに作成し、Web サービス応答オブジェクトを受信したら、それらをローカルの対応するオブジェクトにマップします。私はクライアント ソリューションのファサード プロジェクトでこれを実装する傾向があります。ファサードは、さまざまな Web サービスへのすべての呼び出しを処理し、呼び出しごとにクライアント オブジェクトとサービス オブジェクトの間のマッピングを自動的に行います。とても便利です。

その理由は、Web サービスが提供するオブジェクトを変更することを決定した日には、クライアント アプリケーションのマッピング アルゴリズムを変更するだけで済みます...各クライアント ソリューションの内部コードは変更されないままです。これによりどれだけの労力が節約できるかを過小評価しないでください。

WCF Web サービスの開発は、非常に大きなテーマです。興味のある方には、Programming WCF Servicesという本をお勧めします。.NET のバックグラウンドを持っている人にとっては、WCF 開発のかなり良い入門書となります。

于 2012-11-22T08:42:46.393 に答える
2

私はレビブに完全に同意しますが、いくつかのヒントもあります。

  1. WCF (クレイジーな構成が必要) の代替として、ServiceStackをお勧めします。WCF と同様に、要求を受け取り、事前定義されたオブジェクトの形式で応答を返すことができますが、コードの生成や最小限の構成は必要ありません。JSON、XML、JSV、CSV など、あらゆる種類の応答形式をサポートしています。これにより、f.exからの消費がはるかに簡単になります。JavaScript、さらにはモバイルアプリ。MonoTouch と Mono for Android のバイナリもあります。また、非常にテストしやすく、非常に高速です。

  2. コードのマッピング部分の優れたツールはAutoMapper です。これを使用すると、すべてのマッピングを 1 か所で設定し、単純なメソッドを呼び出すことで、あるオブジェクト タイプから別のオブジェクト タイプにマッピングできます。

それらをチェックしてください！:)

于 2012-11-22T09:09:26.033 に答える
1

何十年にもわたる経験によると、フレームワークを避ければ、解決すべき問題はありません。

フレームワークは癌のように進化します。地獄への道は善意で舗装されており、それらの善意のかなりの部分がフレームワークの巨大な腫瘍に具現化されており、実際には決して起こらない可能性のある再利用の名の下に.

OO と設計に関してある程度の経験と知識を得れば、ファサードや記念品などの技術的な問題に対する無限の解決策を見つけることができますが、それらは実際の問題に対する解決策ではありません。

もう 1 つは、MS テクノロジを使用している場合は、.NET が提供する以上のことを気にしないことです。MS の神々が提供するものに固執すること。

于 2012-11-26T21:36:45.070 に答える