5
votes

Is it possible to create custom entities without implementing ITableEntity or inheriting from TableEntity?

If I am implementing ITableEntity, then it's forcing me to implement some other methods which I don't want to implement.

If I am inheriting my custom entity from TableEntity then I need to new it up before passing it to the table operation, and that's introducing direct dependency which can't be mocked, and my controller class becomes non-testable.

All I want to do is create my custom entity and save in Azure table storage.

2

2 Answers

1
votes

Is it possible to create custom entities without implementing ITableEntity or inheriting from TableEntity?

Stricktly saying: no.
The reason why you need this interface be implemented or this class be inhereted is TableOperation that is taking ITableEntity as argument.

If you really want to be able to use only your own classes and interfaces, then you can implement communication with Azure services by yourself. For example, here is description of Insert Entity operation. You will have to write a wrapper that will...duplicate existing functionality, provided by Microsoft libraries.

But it looks like you are trying to do something strange.
The first strange thing is that you are trying to test a controller. Normally you would not do it. Could you what kind of controllers do you use and why do you want to test them?
The second strange thing is that you are trying to pass something that inherits from TableEntity or implements ITableEntity to some method that is not a repository or some class that works only in data layer.

Normally you would never user something that implements ITableEntity or inherits from TableStorage outside of data layer class. And that class should only read from some storage and retrieve mapped to business objects data or write to some storage, taking as parameters DTO's or business layer objects itself or simple types as string's, int's, DateTime's. And such classes are not testable. It's data layer, you should test business logic or some layers above that one that works with raw data and data storage.

So, consider introducing a new level of abstraction in your system — repository or some analoge, that will work with storage, returning business objects. Such abstraction should have an interface that could be easily mocked and tested. Methods of such class should take business layer objects, DTO's or objects of .NET types. It is only for DI, not for testing. Such classes usually are not tested.

1
votes

Some of the answers are outdated. Yes it is possible. You can use TableEntityAdapter class from storage sdk and instantiate it with your custom object. The object does not need to inherit TableEntity class or implement ITableEntity interface: https://docs.microsoft.com/en-us/dotnet/api/microsoft.windowsazure.storage.table.tableentityadapter-1?view=azure-dotnet