There have long been tools to combat refactoring complexities but one of the more interesting modern ones I've found is NDepend. What specifically intrigues me about this tool is its Code Query Language (CQL), which is NDepend's flagship feature. CQL is a language patterned after SQL that can be used to determine what source code elements meet specified criterion. This allows the developer to effectively understand and navigate the codebase which is critical in developing and refactoring.

To demonstrate I'll need a nicely-sized Visual Studio solution, let's say the Enterprise Library 4.1 application block's source code. According to the report generated after adding the solution to an NDepend project we'll be querying a solution of 1,542 classes spread over 28,281 lines of code which compiles down to 196,966 IL instructions.

Now let's take a look at some actual CQL. Consider the following line:

SELECT TYPES 
WHERE DeriveFrom "System.Drawing.Design.UITypeEditor"

Notice the similarity to SQL. There's a familiar SELECT and WHERE clause. Although this particular statement is lacking a FROM clause they are supported and will be demonstrated later. The TYPES expression indicates that my query will return .Net types such as classes and structs. The DeriveFrom "System.Drawing.Design.UITypeEditor" expression simply stipulates that all types returned will subclass System.Drawing.Design.UITypeEditor.

The result is a list of types that you can select in NDepend and perform a number of actions such as navigating directly to that class in Visual Studio or Reflector as well as viewing dependancy graphs and matrices.

Let's consider another query, this time slightly more complex.

SELECT TYPES 
FROM ASSEMBLIES "Microsoft.Practices.EnterpriseLibrary.Data.Configuration.Design"
WHERE NameLike "Oracle.*Builder"
AND IsSealed 

This query employs a FROM clause which limits the results to the assembly "Microsoft.Practices.EnterpriseLibrary. Data.Configuration.Design". Also the NameLike expression accepts a regular expression which filters the results to types named accordingly. As you may guess the IsSealed expression causes the query to return only sealed classes.

CQL queries need not always be written manually as much of the core NDepend functionality simply writes it for you. Interestingly the software is forthright about this and includes CQL queries directly into its menu system as is shown below.

CQL is certainly one of the most flexible tools a developer can employ to understand a large codebase, especially one they're not entirely familiar with. It's also very intuitive because its set-based query approach is something most developers are already accustomed to. Despite it's simplicity it's very feature-rich and I suggest taking a look at The CQL 1.8 Specification for a more detailed view.

I also suggest taking a look at CQL Constraints which are a more in-depth topic that facilitate proactive management of source code.

One of the most notable initiatives in the business software development industry in the last few years is the simplification of data access. The core complication lies in the impedance mismatch between relational storage and object oriented code higher in the stack. Far too much plumbing is required to map object properties to columns in result sets, deal with data type variations and handle other annoyances.

The most popular response to the problem has been to leave relational storage in place and introduce ORM (Object Relational Mapping) frameworks to automate the conversion between relational and object oriented structures. This approach is popular in business environments because having a relational database under the hood offers many advantages such as ease of reporting and integration.

Object oriented databases, however, offer an interesting alternative.

While I personally think it'll be quite some time before object oriented databases are reasonable for most large-scale enterprise applications they're certainly viable for a range of projects and can be incredibly simple to adopt.

As a demonstration I'll whip up a quick .Net console app that will employ db4o, a popular object oriented database product, to store and query some simple sales order data.

First we need some objects to store. I'll define the following "Order" and "Detail" classes for my application to consume, store and query. Nothing special has to be done to these classes to make them eligible for db40 persistence. This will all be purely POCO.

public class Detail
{
	public int ItemNumber { get; set; }
	public short Qty { get; set; }
}

public class Order
{
	public string CustomerName { get; set; }
	public List<Detail> Details = new List<Detail>();
}

Now I'll set up a connection to a database file. Note that it's also possible for db4o to operate against a server over a network.

IObjectContainer database = Db4oFactory.OpenFile("test.db4o");

Keep in mind that the file "test.db4o" does not have to exist on the filesystem before our code is run. If the file does not exist db4o will create it for us.

Now I'll instantiate some Order and Detail objects and persist them to disk via "Db4oFactory"'s "Store" method.

database.Store(new Order() { CustomerName = "Chris Umbel", 
	Details = new List<Detail>() { 
		new Detail() { ItemNumber = 1, Qty = 3} 
	} 
});

database.Store(new Order() { CustomerName = "Billiam Smith", 
	Details = new List<Detail>() { 
		new Detail() { ItemNumber = 1, Qty = 1 }, 
		new Detail() { ItemNumber = 2, Qty = 1} 
	} 
});

That was pretty easy and about as plumbing free as could be hoped for. Now I'll use Linq to query what we've stored.

IEnumerable<Order> orders = 
	from Order o in database 
	from Detail d in o.Details
	where d.ItemNumber == 2
	select o;

foreach (Order o in orders)
{
	Console.WriteLine(o.CustomerName);
}

Which produces the following output:

Billiam Smith

because that was the only order stored containing an item #2.

db40 also offers other methods of querying than Linq such as their "Native Query" implementation, Query-By-Example and the SODA API, but they're beyond the scope of this introduction.

As a final matter of housekeeping I'll clean up after myself and close my connection to the database file.

database.Close();

Based on that simple example it's evident that persisting objects with db4o is painless and requires minimal plumbing to implement. More importantly still it does not impose any restrictions on the inheritance chain so you can subclass however you chose.

There are plenty of other object oriented database systems out there each with their own strengths and weaknesses. I recommend checking out ODBMS.org for more info on the subject.

If there's one thing I'm not passionate about, however, it's web interface work. I'm very glad technologies like jQuery exist but I'm ecstatic it's other people's jobs to work with them. But, I have no choice but to do some web work on occasion. Whether it's for simple administrative tools at the office or even the development of this very website sometimes I simply must write web interface code.

With both of those concepts on the brain I decided to take a stab at consuming an ADO.Net data service from jQuery for a personal project I'm working on. The result. Easy as falling off a log.

To illustrate an example we have to start out with a web project containing an entity model. For those of you who are unfamiliar with generating models it's outlined here. In this case I'll just create a simple, single table model that will house the names of hockey players. Note that this will require downloading and including the jQuery and JSON javascript libraries into the project.

There isn't too much to do to get our service to work with our model. Just change the parent class of our service to employ our entity model in the constructed type and the access rules. Because this is just an example we'll allow the service to modify Player entities without restriction.

public class HockeyDataService : DataService<HockeyEntities>
{
	public static void InitializeService(
	    IDataServiceConfiguration config)
	{
      	config.SetEntitySetAccessRule("Players", EntitySetRights.All);
	}
}

That's it, our service is ready. Run your web project and it's good to go. The time has come to consume the service from client-side javascript on a web page. Here's a basic layout for a button to retrieve our list of players, provide a place to put the list, and a form to create a new player.

<button onclick="return getPlayers();">Get Players</button>
        
<div id="_players" style="width:400px;height:100px;">
</div>
        
<div id="_edit" style="position:absolute;width:400px;height:100px;
            left:200px;top:10px;">
        <input type="text" id="_firstNameTextBox" />
        <input type="text" id="_lastNameTextBox" />
        <button onclick="return addPlayer($('#_firstNameTextBox').val(), 
            $('#_lastNameTextBox').val());">Add</button>
</div>

Now for the magic. We're just going to use simple jQuery AJAX calls to our service with the HTTP verb GET to retrieve our players and POST to save a player as is outlined in the following script. I'm not going to cover it here, but the PUT and MERGE verbs can be used for updating while the DELETE is used for, you guessed it, deleting.

<script>
function getPlayers() {
    $("#_players").html("");

    $.ajax({
        type: "GET",
        url: "HockeyDataService.svc/Players",
        data: "{}",
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function(data) {
            displayPlayers(data.d);
        },
        error: function(xhr) {
            alert(xhr.responseText);
        }
    });
    
    return false;
}

function addPlayer(firstName, lastName) {
    var player = { FirstName: firstName, LastName: lastName };

    $.ajax({
        type: "POST",
        url: "HockeyDataService.svc/Players",
        data: JSON.stringify(player),
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function(data) {
            displayPlayer(player);
        },
        error: function(xhr) {
            alert(xhr.responseText);
        }
    });

    return false;
}

function displayPlayer(player) {
    $("#_players").html($("#_players").html() + "<div>" + 
        player.FirstName + " " + player.LastName + "</div>");
}

function displayPlayers(players) {
    for (var i in players) {
        displayPlayer(players[i]);
    }
    return false;
}

</script>

And that's pretty much all there is to it. Most of the data access and service layers were auto generated. Not too shabby for such a small amount of work.

I'd like to share a few that I've found useful not only for keeping me up to date on the latest and greatest software development news but to pass the time during my 60 miles of driving every day. Keep in mind to play these you only need podcatching software, not necessarily an iPod or other portable mp3 player.

.Net Rocks! - This is a great podcast hosted by Richard Campbell and Carl Franklin centered around .Net development. They have awesome guests, typically program managers at Microsoft or MVPs. If you're a .Net developer and you're only going to subscribe to one podcast this is the one right here.

Hanselminutes - This podcast generally focuses on ASP .Net development and is hosted by Scott Hanselman, who is now a Microsoft employee. Much like .Net Rocks the format involves a guest. This podcast overflows with expertise in my opinion.

SSWUG Radio - This is the official podcast of the SQL Server WorldWide User Group. It's generally a monolog hosted by Stephen Wynkoop and useful both to DBAs and more casual database developers. The focus is clearly on SQL Server but Oracle, DB2 and MySQL topics are covered on occasion.

SQL Down Under - An Australian SQL Server podcast hosted by Greg Low. It has a typical interview format with knowledgeable guests.

Polymorphic Podcast - Here's another .Net podcast, this one hosted by Carig Shumaker. This guy works for Infragistics, a user interface company. The cast is very instructional and tutorial-esque in nature.

Going Deep - A Channel 9 MSDN podcast with interviews with the architects who work for Microsoft. They discuss the innards and design of the platform.

sd.rb - The san diego ruby user group's video podcast. Essentially it's recordings of presentations at their meetings. Topics are wide ranging and quite informative.

Biznik - The official Ruby on Rails podcast.

I was basically trying to pull attachments out of unread mails with specific subjects and mark the owning mail as read. My first move was strait to CDO... Low and behold microsoft REALLY does not want you using CDO from within .net (generally not supported except for circumstances incompatible with my needs) and accessing exchange via ADO is supported only on the exchange server itself and this was prohibited by circumstances beyond my control.

Since I wasn't prepared to use CDOX in an unsupported fashion the only real option I had available was to issue commands to exchange via webdav. It seemed klunky at first, but turned out to be quite handy. You really can go far with automating exchange by HTTP, and I don't mean total hacks like faking browser requests to web outlook.

Consider the following code:

/* send the webdav query */
XmlDocument inboxXml = new XmlDocument();
HttpWebRequest request = (HttpWebRequest)WebRequest.
Create("http:/mail.mydomain.com/exchange/myuser/inbox/");

/* impersonate current process */
request.Credentials = CredentialCache.DefaultCredentials;
request.ContentType = "text/xml";

/* the actual name of our command */
request.Method = "PROPFIND";

/* read the response back from exchange */
HttpWebResponse response = (HttpWebResponse)request.GetResponse();

using (StreamReader reader = 
new StreamReader(response.GetResponseStream()))
{
    inboxXml.LoadXml(reader.ReadToEnd());
}

/* xsd plumbing so our xpath queries will work */
XmlNamespaceManager namespaces = 
new XmlNamespaceManager(inboxXml.NameTable);
namespaces.AddNamespace("a", "DAV:");
namespaces.AddNamespace("d", "urn:schemas:httpmail:");

/* iterate all items in mailbox that are 
proper unread DotCom messages */
foreach (XmlNode mailNode in inboxXml.
SelectNodes(@"/a:multistatus/a:response/a:href", namespaces))
{
    Console.WriteLine(mailNode.InnerText);
}

That code simply asked exchange for a list of mails in a specific mailbox.

Look at where we set the request method, "PROPFIND" in this case. Think of that a function name. It tells the server what action to do i.e. get the properties of a mailbox. Not listed above but also used in my program were "X-MS-ENUMATTS" and "PROPPATCH" list attachments and set an email's state to "read" respectively.

You issue arguments to these webdav requests similarly to how the POST HTTP method works by writing to the request stream before reading the response like so:

byte[] bytes = Encoding.UTF8.GetBytes((string)query);
request.ContentLength = bytes.Length;
System.IO.Stream requestStream = request.GetRequestStream();
requestStream.Write(bytes, 0, bytes.Length);
requestStream.Close();

where the object "query" is a string such as

<?xml version='1.0'?>
<D:propertyupdate xmlns:D='DAV:' xmlns:hm='urn:schemas:httpmail:'>
 <D:set>
  <D:prop>
   <hm:read>1</hm:read>
  </D:prop>
 </D:set>
</D:propertyupdate>

I suppose this may seem like an off the wall way of talking to exchange but it can be quite handy.