Using Domain Console to Migrate Entities
As I mentioned in a previous post, Jim referred to on Twitter and officially named it, we’ve been tinkering with the idea of using Powershell and NHibernate together to move entity instances between persistence mechanisms. I’m going to cover how one can accomplish this functionality using Domain Console in this post. If you prefer just looking at PS1 files, a code download is available at the end of the post.
First, let’s clarify what I see as the goals for Domain Console. Jim’s may be different, or more advanced [probably the case] than I can surmise right yet. He’ll blog soon enough on this whole thing, I’m sure. My goal was simple when I created the NHQS – NHibernate Quick Start – library; make it easy to share database connections in one application and as simply as possible using NHibernate. Mutually inspired by the configurability of the enterprise library’s data access functionality and the Sharp Architecture’s approach to NHibernate, TDD, and MVC, I created the NHQS. So obviously, we’ve come to goal #1:
Facilitate an example using NHQS that could work in a real-world situation and make life easy, but not just for enterprise developers. Make NHibernate simple via the NHQS, and then exemplify it somehow nifty.
Jim’s examples and demonstrations of using Powershell’s custom drive capability led us both to thinking we had a nice combination. Logically this brings us to the ultimate goal of Domain Console:
Use NHQS to provide the backing persistence mechanism for Powershell drives. Provide as much native functionality as possible so that transmission of persisted objects between database platforms is as easy as building an NHQS ISessionFactory provider mechanism and wiring them up as a drive in Powershell, and then a user can copy objects between databases. The object relationships would be maintained as deep as you’d want (or deeper), and you could use copy or Copy-Item method calls like normal to migrate data.
With that introduction out of the way, take a look at the Geek Night domain model. It represents an idea that came out of some variance in meeting room opportunities and ideas. Point is, it isn’t that complex an object model and represents a pretty easy example to demonstrate the functionality of Domain Console.
This example will be creating a SQLite drive and a Microsoft SQL Drive, and then copying data from one to the other. To do that, there are a few supporting NHQS interfaces for which implementation is needed. Note the distinction/coupling between the pairs of services. 
Now that two providers have been created for the same domain model the drive-creation and usage can begin. The first few lines of the PS1 sample included in the accompanying download set up the Powershell host with all the assemblies it’ll need to perform the various operations. Specifically, the Geek Night domain and core assemblies are loaded, as well as the NHQS assembly and the SQLite resource assembly.
Once all the required assemblies are loaded by Powershell the heavy lifting can begin. First, as in the previous example, a SQLite-backed drive is created named GeekNightSQLite. Then, a second drive is created using a Microsoft SQL Server 2008 database named GeekNightMSSQL. Note again the distinction between the providers.
Now that the drives have loaded it’s time I point out the smoke-and-mirrors part of this demo. One of the providers will load data into the database, the other will not. Right off the bat, the SQLite database has data. The SQL Server isn’t loaded with anything.
As the PS1 continues to execute the Geeks are queried via the Powershell Get-Item command from the database and constructed by NHibernate as Geek class instances. They’re then displayed in the Powershell console window.
The next part of the PS1 script will create a new Geek object in memory as a variable. Then, it’ll call the Powershell New-Item command to save that instance to the SQLite database.
In the Powershell console one can easily see that the persistence and retrieval is functioning as expected. We’re actually persisting instances of objects to a SQLite database and then retrieving them again using LINQ queries the the Get-Drive’s filter argument.
Finally, the good stuff. Remember the GeekNightMSSQL drive that was also created? The last few lines of the PS1 file do the copying. They actually query the SQLite database using LINQ and take the resulting Geek (or Geeks) and put them into the SQL Server database. The key is in the destination argument, which takes the drive name and path.
The screen shot below shows the Powershell command window output and a shot of SQL Server Management Studio with the single record inserted into SQL Server via this Domain Console example.
As mentioned earlier in the post the assemblies and PS1 are available for download. Happy coding!