DbFS.NET

Description
Why DbFS.NET
Main Functions
How It Works
Download

Description

DbFS.NET is a high-level abstraction and implementation, which supports files (with versions and branches) in the MS SQL database.

For many enterprise-level purposes, we should keep everything in solid ACID storage and keep history for everything, including named BLOBs. DbFS.NET is based on the BLOBs in MS SQL. The approach is similar to version control systems, so with our solution, we provide the “native” way for programmers to manage unstructured contents.

1 var dbfs = new DBFS();
2 using (var commit = dbfs.StartCommit("Text", "admin", "Branch")) {
3 commit.AddFile(path, p => new
4 MemoryStream(Encoding.UTF8.GetBytes(content)));
5 commit.Finish();
6 }

1 var dbfs = new DBFS();
2 var list = dbfs.GetFilesList("Branch", "/folder/to/path/we/need").Select(e => e.Path);

Why DbFS.NET

DbFS.NET is a complete solution you can use in your applications immediately with EntityFramework model, database scripts, unit tests and even a command-line tool supporting bulk uploads and downloads of the content from the storage. Optionally, we have an ASP.NET MVC module for file maintenance visually.

Main Functions

DbFS.NET supports all typical operations that you might need:

Branches (create, list, use, delete).
Transactions (commit sets).
Folders and Files.
Full history: every change refers to a specific commit, and every file change (including addition or deletion) is tracked as a history change.
Copy/Move file semantic without manual addition/removal.
Database transactions automatic support.
FILESTREAM support.
Big files support (GB).

How DbFS.NET Works

DbFS.NET creates independent informational schema into your database and provides everything to work, including Files, Blobs, Branches, Commits, FileRevisions tables with all necessary indexes and stored procedures.

The underlying implementation is supported by EntityFramework models; so you just need to use the DbFS.NET service layer to manage all your data. If you need to go deeper, we have repositories for all underlying objects.

The database schema scripts are very simple and contain a database structure and initial contents (one branch named “Start” without files inside).

When you’re starting committing, all further operations are being collected into operations stack (with optimizations: if you add a file and then update it several times, the final data to commit will contain only one file with the real content, all intermediate changes won’t be accepted). The actual data will be updated in the database while the commit is being finished by Finish() call; the EF’ SaveChanges() method will be used automatically.