Как создать пользовательский объект без наследования от TableEntity или реализации ITableEntity

Question

Возможно ли создание пользовательских объектов без реализации ITableEntity или наследования от TableEntity?

Если я реализую ITableEntity, то это заставляет меня реализовать некоторые другие методы, которые я не хочу реализовать.

Если я наследую свой пользовательский объект из TableEntity, мне нужно его обновить, прежде чем передавать его в таблицу, и это вводит прямую зависимость, которую нельзя издеваться, и мой класс контроллера становится не проверяемым.

Все, что я хочу сделать, это создать мой пользовательский объект и сохранить его в хранилище таблиц Azure.

Answer 1

Возможно ли создание пользовательских объектов без реализации ITableEntity или наследования от TableEntity?

Слишком говоря: нет.
Причина, по которой вам нужен этот интерфейс, должен быть реализован или этот класс должен быть установлен: TableOperation, который принимает в качестве аргумента ITableEntity.

Если вы действительно хотите использовать только свои классы и интерфейсы, вы можете самостоятельно реализовать связь с Azure. Например, here - описание операции Insert Entity. Вам придется написать оболочку, которая будет ... дублировать существующие функции, предоставляемые библиотеками Microsoft.

Но похоже, что вы пытаетесь сделать что-то странное.
Первой странной вещью является, что вы пытаетесь протестировать контроллер. Обычно ты этого не делал. Можете ли вы, какие контроллеры вы используете, и почему вы хотите их протестировать?
Вторая странная вещь:, что вы пытаетесь передать что-то, что наследует от TableEntity, или реализует ITableEntity для некоторого метода, который не является репозиторием или каким-либо классом, который работает только в слое данных.

Обычно вы никогда не пользовались бы тем, что реализует ITableEntity или наследует от TableStorage за пределами класса слоя данных. И этот класс должен считывать только из некоторого хранилища и извлекать , сопоставленные с бизнес-объектами, или записывать их на хранение, принимая в качестве параметров Объекты DTO или бизнес-уровня сами или простые типы, такие как string, int, DateTime. И такие классы не проверяются. Это слой данных, вы должны протестировать бизнес-логику или несколько слоев выше той, которая работает с необработанными данными и хранилищем данных.

Итак, рассмотрите возможность введения нового уровня абстракции в вашей системе - хранилище или какой-либо аналог, который будет работать с хранилищем, возвращая бизнес-объекты. Такая абстракция должна иметь интерфейс, который можно было бы легко высмеять и проверить. Методы такого класса должны принимать объекты бизнес-уровня, DTO или объекты типов .NET. Это только для DI, а не для тестирования. Такие классы обычно не проверяются.

Answer 2

Похоже, вы уже определили ответственность, которую хотите отделить от своего контроллера - назначение пользовательских свойств. Не поможет ли это, если вы переложите эту ответственность на другой интерфейс и позвольте контроллеру использовать этот интерфейс в качестве зависимости через свой конструктор. Этот интерфейс может быть чем-то вроде одного метода, который выполняет преобразование.