ビジネス オブジェクトに画像を保存したいと考えています。MSDN で、System.Drawing-namespace が多くの GDI+ 機能などを提供していることを見ました。
Image を System.Drawing.Image クラスのビジネス層 (クラス ライブラリ「のみ」) に保存して、System.Drawing への参照も含めても問題ありませんか? ビジネスコードにUI固有の参照があるように見えるので、それを行うのは少し悪いと感じています。さらに、コードが不必要にプラットフォームに依存する可能性があります (ただし、これは理論上の問題にすぎません。複数のプラットフォーム向けに開発を行っていないためです)。
そうでない場合、どのタイプが最も適していますか?
返信ありがとうございます。
マティアス
あなたの質問から、ビジネス ロジック層がかなり低レベルの方法で画像を処理する必要があることは明らかです (そうでなければ、画像の URL などを保存しているだけだと思います...)。これにより、イメージ/ビットマップの概念がビジネス ロジックの領域に真っ向から置かれるため、この目的で System.Drawing 名前空間に依存することはまったく問題ありません。
画像がクラス ライブラリに存在しないと感じた場合は、System.Drawing 自体を一目見ただけで納得できるはずです。それはクラス ライブラリの代表的な例であり (非常に適切に設計されたものです)、処理以外のことはほとんど何もしません。画像付き。
実際には UI とは何の関係もありません (Windows.Forms とその仲間がそれらを扱っています)。また、System.Drawing は .NET Framework がインストールされているすべてのシステムに存在するため、依存関係の問題はありません。
クロスプラットフォームの互換性が気になる場合は、イメージのラッパー クラスを作成すると、これらの問題が軽減される可能性があります。ただし、ビットマップ構造自体はすでにプラットフォーム固有である可能性が高いため (たとえば、外部インターフェイスで PNG のみを使用するように注意しない限り)、これは少しやり過ぎかもしれません。 ..