One Library To Rule Them All
I'm really sure why there are so many similar storage providers performing almost identical function but no standard. Why do we need to learn a new SDK to achieve something trivial we've done so many times before? I have no idea. If you don't, use this library.
Storage.Net abstracts storage implementation like blobs, tables and messages from the .NET Applicatiion Developer. It's aimed to provide a generic interface regardless on which storage provider you are using. It also provides both synchronous and asynchronous alternatives of all methods and implements it to the best effort possible.
Storage.Net supports Azure Service Bus, Azure Event Hub, Azure Storage, Azure Data Lake Store, Amazon S3, Azure Key Vault and many more, out of the box, with hassle-free configuration and zero learning path.
Storage.Net also implements inmemory and on disk versions of all the abstractions, therefore you can develop fast on local machine or use vendor free serverless implementations for parts of your applciation which don't require a separate third party backend at a particular point in development.
This framework supports .NET 4.5.2 and .NET Standard 1.6, and most of the implementations exist for all frameworks.
Storage.Net defines three different storage types:
- Blob Storage is used to store arbitrary files of any size.
- Messaging is an asynchronous mechanism to send simple messages between disconnected systems.
- Table Storage is a simplistic way to store non-relational tabular data.
There are various implementations/providers of different storage types:
- In-Memory
- Local Disk
- Microsoft Azure
- Amazon S3
- Microsoft SQL Server
All contributions of any size and areas are welcome, being it coding, testing, documentation or consulting. The framework is heavily tested under stress with integration tests, in fact most of the code is tests, not implementation, and this approach is more preferred to adding unstable features.
Storage.Net tries to enforce idential behavior on all implementaions of storage interfaces to the smallest details possible and you will find a lot of test specifications which will help you to add another provider.
The solution is created in Visual Studio 2017 (Community Edition).
When I think of the best way to document a framework I tend to think that working examples are the best. Adding various real world scenarios with working code is more preferrable than just documenting an untested API.
Please use the GitHub issue tracker to do this.
You can get support by raising an issue here, or contacting me directly for consulting services.