Best practice of using TableEntity (Azure table storage) - decoupling of classes

I'm prototyping right now on a bigger project and need to make some design decisions..

My VS Solution consists (for now, might separate it further later) of 4 projects:

• A .NET Standard 2.1 project with all my entities (e.g. a Customer class), containing mostly simple properties, but some also contains enumerations and lists. I want this be simple with no dependencies.
• A Web project using ASP.NET Core 3.1 and Blazor WebAssembly (client-side only)
• An Application project containing the infrastructure and services (e.g. this is where AzureTableStorage<T> resides)
• An Azure Function layer that is the 'mediator' between web and application, which depends on Application layer (injects the CustomerService)

For storage I'm using Azure storage table, and my problem is to find an elegant decoupled way of implementing this.

I'm using this example more or less: https://www.c-sharpcorner.com/article/single-page-application-in-blazor-with-azure-table-storage/ for CRUD operations to the tables.

But in order to use this I'm relying on inheriting TableEntity, which is annoying. Also my WebUI is using Blazor, so it takes in a bunch of Azure Cosmos dll to the browser that is not needed if I choose to inherit TableEntity.

So I can't decide if I just need to pursue decoupling my poco classes and get rid TableEntity.. I saw something about using TableEntityAdapter, but can't find any example using it?

Another approach might be to have Dto "duplicate" classes of my POCO classes, which then could inherit the TableEntity. But then I would need to maintain these classes. But might be needed since I don't think the methods in Azure Storage library can handle lists, enumeration etc. out of the box. But then again if I can make some generic adapter that takes care of more complex types, a Dto class could be redundant.

Looking for input and inspiration basically :)

Thanks