Как создать пользовательский объект без наследования от TableEntity или реализации ITableEntity
Можно ли создавать пользовательские объекты без реализации ITableEntity или наследования от TableEntity?
Если я реализую ITableEntity, то это заставит меня реализовать некоторые другие методы, которые я не хочу реализовывать.
Если я наследую свой пользовательский объект от TableEntity, то мне нужно его обновить перед передачей в табличную операцию, и это вводит прямую зависимость, которая не может быть смоделирована, и мой класс контроллера становится не тестируемым.
Все, что я хочу сделать, - это создать свой собственный объект и сохранить его в хранилище таблиц Azure.
2 ответа
Можно ли создавать пользовательские объекты без реализации ITableEntity или наследования от TableEntity?
Строго говоря: нет.
Причиной, по которой вам нужен этот интерфейс или этот класс наследуется, является TableOperation, который принимает ITableEntity в качестве аргумента.
Если вы действительно хотите иметь возможность использовать только свои собственные классы и интерфейсы, то вы можете реализовать связь со службами Azure самостоятельно. Например, вот описание операции Вставить объект. Вам нужно написать оболочку, которая будет... дублировать существующие функции, предоставляемые библиотеками Microsoft.
Но похоже, что вы пытаетесь сделать что-то странное.
Первая странная вещь - вы пытаетесь протестировать контроллер. Обычно вы бы этого не делали. Не могли бы вы узнать, какие контроллеры вы используете и почему вы хотите их протестировать?
Вторая странная вещь заключается в том, что вы пытаетесь передать что-то, что наследуется от TableEntity или реализует ITableEntity, в некоторый метод, который не является репозиторием, или в некоторый класс, который работает только на уровне данных.
Обычно вы никогда не будете использовать что-то, что реализует ITableEntity или наследует от TableStorage вне класса уровня данных. И этот класс должен только читать из некоторого хранилища и извлекать сопоставленные с данными бизнес-объектов или записывать в какое-то хранилище, принимая в качестве параметров сами объекты DTO или бизнес-уровня или простые типы, такие как string, int, DateTime. И такие занятия не поддаются тестированию. Это слой данных, вы должны проверить бизнес-логику или несколько слоев выше того, который работает с необработанными данными и хранилищем данных.
Итак, рассмотрите возможность введения в вашей системе нового уровня абстракции - хранилища или некоторого аналога, который будет работать с хранилищем, возвращая бизнес-объекты. Такая абстракция должна иметь интерфейс, который можно легко смоделировать и протестировать. Методы такого класса должны принимать объекты бизнес-уровня, DTO или объекты типов.NET. Это только для DI, а не для тестирования. Такие занятия обычно не тестируются.
Похоже, вы уже определили ответственность, которую вы хотите отделить от вашего контроллера - назначение пользовательских свойств. Тогда это не поможет, если вы перенесете эту ответственность на другой интерфейс и позволите контроллеру воспринимать этот интерфейс как зависимость через своего конструктора. Этот интерфейс может быть чем-то вроде одного метода, который выполняет преобразование.