TableEntityを継承せずに、またはITableEntityを実装せずにカスタムエンティティを作成する方法

Question

ITableEntityを実装せずにカスタムエンティティを作成することも、TableEntityから継承することもできますか？

ITableEntityを実装している場合、実装したくない他のメソッドを実装する必要があります。

TableEntityからカスタムエンティティを継承している場合は、テーブル操作に渡す前にそれを新しいものにする必要があります。これは、モックできない直接の依存関係をもたらし、コントローラクラスはテスト不可能になります。

私がしたいのは、私のカスタムエンティティを作成し、Azureテーブルストレージに保存することです。

Answer 1

ITableEntityを実装せずにカスタムエンティティを作成することも、TableEntityから継承することもできますか？

Stricktly say：いいえ。
このインターフェイスが必要な理由は、このクラスが内在するTableOperationで、これは引数としてITableEntityとなります。

独自のクラスとインターフェイスだけを本当に使いたい場合は、Azureサービスとの通信を自分で実装することができます。たとえば、hereは、エンティティの挿入操作の説明です。 Microsoftライブラリが提供する既存の機能を複製するラッパーを作成する必要があります。

しかし、あなたは何か変なことをしようとしているようです。
最初に奇妙なことはコントローラをテストしようとしているです。通常、あなたはそれをしません。どのような種類のコントローラーを使用できますか、なぜそれらをテストしたいのですか？
2番目の奇妙なことは、TableEntityから継承するものを渡そうとしているか、またはITableEntityをリポジトリではないメソッドまたはデータレイヤーでしか動作しないクラスに渡そうとしているです。

通常、ITableEntityを実装するもの、またはデータレイヤークラスの外でTableStorageから継承するものはユーザーには決して使用されません。そのクラスは、いくつかのストレージから読み取って、ビジネスオブジェクトのデータにマップされたを検索するか、またはパラメータとしてDTOまたはビジネスレイヤーオブジェクト自身または単純な型を文字列、int、DateTimeのとして取る必要があります。そしてそのようなクラスはテスト可能ではありません。それはデータレイヤーで、生データとデータストレージで動作するビジネスロジックまたはその上のいくつかのレイヤーをテストする必要があります。

したがって、システムで新しいレベルの抽象化を導入することを検討してください。レポジトリまたはストレージと連携してビジネスオブジェクトを返すような類似のものもあります。そのような抽象化は、容易に嘲笑され、テストされるインターフェースを有するべきである。そのようなクラスのメソッドは、ビジネス層オブジェクト、DTO、または.NETタイプのオブジェクトを取る必要があります。それはテスト用ではなく、DI用です。そのようなクラスは通常テストされません。

Answer 2

コントローラから切り離して、カスタムプロパティを割り当てるという責任は既に分かっているようです。その責任を別のインターフェースに移し、コントローラーがそのインターフェースをそのコンストラクターを介して依存関係にすることができればそれは役に立ちませんか？そのインタフェースは、変換を行う単一のメソッドのようなものにすることができます。