5

2 つの世界の間でビジネス ロジックを再利用できるように、.NET クラス ライブラリ、または少なくともその一部を Silverlight に移行するのにどれだけの作業が必要かを確認するために、小さな実験セッションを行ったところです。他の人がこの種の経験を持っているかどうか疑問に思っています。

私が気づいたこと、私の頭の上から：

  • 多くの属性が欠落しています (たとえば、Browsable(false))
  • 多くのインターフェイスが欠落しているか、存在するが空である (ICloneable が非表示、ITypedList が欠落している)
  • リフレクションの違い (到達可能なものはすべて公開する必要があります)
  • いくつかの基本クラスの違い (コンポーネントがない?)

だから私は疑問に思っています、これを可能性として見ることさえ本当に実現可能ですか？

最初のコードを実行しましたが、ITypedList といくつかの基本クラスに基づいているため、主にリストの処理に関する多くの基本機能をコメントアウトする必要がありました。どうやら、Silverlight で ObservableCollection に変更する必要があるようです。対応するには、ベース コード全体を変更する必要があります。

私が作成した実際のビジネス テスト クラスは、.NET 用に作成したものと 99.5% 同一です。.NET でも簡単に使用できる小さな変更がいくつかあるだけです。シルバーライト。つまり、基本クラスの互換性を確保できれば、ビジネス ロジックを共有することは可能に見えます。

明確にするために、私が話していることは、基本的には .NET 用と Silverlight 用の 2 つのプロジェクト ファイルを持つことになりますが、実際の C# ソース コードは同じで、2 つの間で共有されるということです。

それで、誰もこれについて何か経験がありますか？ヒントやガイドラインはありますか？

それはそれだけの価値がありますか？それは確かにもっと調べる必要があります。

4

4 に答える 4

4

それは間違いなく実現可能です。

ここのプロジェクトで行われます。Silverlight プロジェクトには C# プロジェクトが含まれており、いくつかの#IF処理 (log4net 宣言など) を処理するステートメントがいくつかあり、それ以外の場合は単に再実装されています。しかし、一般的には、これは大きな勝利であり、ぜひ試してみる必要があります (そして、確かに成功しています)。

- 編集：

ただし、1 つのポイントとして、OR/M (LLBLGen) には、Silverlight を介して送信される「単純な」オブジェクトの組み込みサポートがありませんでした。しかし、誰かがそれを処理するプラグインを書いていて、それが役に立ちました。そのため、使用している DAL の種類と、それが Silverlight をどの程度サポートしているかを検討する価値があるかもしれません。

于 2010-01-10T21:57:34.157 に答える
4

これを容易にするために私が行ったことは次のとおりです。

  1. 部分クラスと #if !SILVERLIGHT を頻繁に使用して、Silverlight が処理できる部分にコードを分割します。
  2. 可能な限りコード生成を使用します。たとえば、Silverlight と同等の属性 (たとえば、DescriptionAttribute ではなく DisplayAttribute) を生成する T4 テンプレートを試してみました。
  3. Silverlight によって実装されていないインターフェイス/属性 (IDeserializationCallback、ICloneable、INotifyPropertyChanging など) がある場合はいつでも、Silverlight アプリケーションで同じ名前のダミー インターフェイスを作成します。使用することは問題ありません。
  4. 最後に、 Silverlight 4では、Silverlight がサポートしない依存関係がない限り、アセンブリ形式により、Silverlight と .NET の間でバイナリを共有できることに注意してください。

別の基底クラスに関するもう 1 つの注意点 - 型指定されたコレクションへの影響を最小限に抑えるために、Silverlight および BindingList (または .NET で使用しているもの) で ObservableCollection から派生する抽象クラスを作成する価値がある場合があります。

アップデート 今日、私は Silverlight に存在しない TraceSource、SourceSwitch などの System.Diagnostics API を多用する .NET コードを Silverlight に移植する作業を行っていました。私は Silverlight プロジェクトでこれらの最小限の実装を作成し、Einstein.Diagnostics 名前空間に配置しました。そうすることで、.NET Framework を模倣しているコードと自分のコードを簡単に識別する規則が必要であると判断しました。そこで、プレースホルダー ファイルの名前を変更して、先頭に @ 記号を付けました。これらのファイルのクラス名にも接頭辞を付けました。これの良いところは、C# コンパイラに関する限り、@ 記号が実際にクラス名を変更しないことです。したがって、@SourceSwitch は引き続き Einstein.Diagnostics.SourceSwitch にコンパイルされますが、コードで何かが起きていることが簡単にわかります。私'

于 2010-01-10T22:10:57.123 に答える
2

私はこれを protobuf-net で行い、いくつかのアプローチを使用します。

  • 微妙なコード分岐をトリガーするプロジェクト ファイル内の条件付きコンパイル シンボル (はい、完全ではありませんが、機能します)
  • いくつかのものの再導入; 属性はここでの例かもしれません-フレームワークコードがそうでなくても、コードは再導入された属性を引き続き使用できます。Expressionこれのより極端な例として、コンパクトなフレームワークの場合、 APIのかなりの部分を再導入する必要がありましたが、これは楽しかったです
  • いくつかのものをドロップしてください;-p

ただし、（あなたが言及している）を使用している場合ITypedList、そのアプローチ全体がかなり乱雑に崩壊していることがわかります。component-model はすでに十分に複雑であり、ハックを強制的に通過する必要はありません。それは、あなたがこの道をどれだけ進んだかにかかっています。おそらく 4.0 /dynamicこれらのオプションのいくつかが再び開かれるでしょうか?

于 2010-01-10T22:34:49.667 に答える
2

問題の解決策の 1 つは、欠落しているコードを Mono プロジェクトからコピーすることです。以前、Compact Framework を使用して小規模なプロジェクトを行ったところ、System.XLM 名前空間全体が欠落していました。Mono からすべてを自分のプロジェクトにコピーしてコンパイルしたところ、最小限の変更でうまく機能しました、iirc。

于 2010-01-10T22:38:11.080 に答える