Wednesday, November 14, 2012

Sql Server 2012 FileTable & Nhibernate

In the project I'm currently working on we're taking advantage of Sql Server's 2012 FileTable feature. Windows API compatibility allows our users to use windows explorer to batch "upload" literally hundreds of documents at a time and allows for easy/familiar file management. We also need a way to link to files from what we are calling DocumentExtensions. The general use case is a user uploads files/folders to the application using the virtual network share that sql server creates. Then they use a web application to link selected files/folders to DocumentExtensions.

Call me old school if you like but we still rely heavily on Nhibernate as our ORM. I just haven't found a compelling reason to switch to Entity Framework. So here's the problem, we want to use Nhibernate to link DocumentExtensions to files/folders that have already been uploaded.

Here's an integration test to help explain what is needed:



First off, this is an integration test that interacts with a real database. Also, I'm using the Builder patter to create real services instead of mocking things out. This test is not the fastest but it gives me a great deal of confidence that what I've implemented actually works all the way from the top to the bottom. I find this very comforting especially when working on techniques that are new to me.

So the ApplicationDocumentsFileTable is an abstraction that allows me to easily gain access to the DirectoryInfo object at the root of the FileTable. I find myself creating a bunch of little abstractions on top of the FileTable features. I'm using this to create a temp file at the root of the FileTable.

Next is the PathLocatorResolver is yet another one of these FileTable abstractions I'll get into in a bit.

Once I create the temp file, I create a DocumentExtension entity that I then want to have linked to the temp file. After the link is created I Save, Flush, and clear the Nhibernate session. To prove that everything was persisted correctly I grab the link by it's id and check to make sure the properties equal the properties from the link that was created above. I'm excluding the PathToPhysicalDocument property because as you'll see, this is a property based off an Formula.

Alright, on to the implementation:



There is a lot going on here that I'm not going to explain now. The interesting thing here is the IPathLocatorResolver. If you remember I built one up in the test and explicitly passed it into the AddLink method. Well I stick to the thought that it is bad to inject services into domain entities but when you must use the Double Dispatch pattern. This service is responsible for taking a path to a document and resolving it to a FileTable path locator hierarchyid.



This just leaves the DocumentExtensionLink entity:

No comments:

Post a Comment