Design Notes

For those that want to change or improve CrissCross, these notes describe how it is currently designed.


CrissCross is a .NET 3.5 app built from a Visual Studio 2008 Solution. I wrote CrissCross while at a client site, and they kindly allowed me to open-source it. VS2008 was the platform they were using at the time. I plan to upgrade it to VS2010 or VS2012 and .NET 4 or 4.5 soon.

Solution Structure

The VS2008 Solution contains three projects:
  • CrissCrossLib - this is a .NET asseembly that does all the work - communicating with the web service, processing parameters, etc
  • CrissCrossTest - this is a batch of unit tests for Visual Studio's inbuilt VSTest framework. Most of the major features in CrissCrossLib have corresponding tests. Mocks are provided by Rhino.Mocks
  • CrissCross - this is the front-end ASP.NET project that the user interacts with.


The user interface is an ASP.NET project - I would have preferred to write it in MVC, but because the ReportViewer component is so important to the project, and it prefers to run in ASP.NET, I had to go for ASP.NET.

However most of the user interaction in CrissCross is facilitated by jQuery making AJAX calls to ASP.NET Page Methods, and traditional ASP.NET postbacks are only really used when the user presses the Run Report button.

The most important part of the CrissCriss UI is the displaying of parameter options to the user, and gathering their input. This is performed entirely with javascript and jQuery, mostly by fetching Json data from the server and then rendering it into HTML on the client-side.

Most of the key client-side javascript is encapsulated in the file CrissCross\Scripts\CrissCrossClient.js, apart from a few features related to giving the user an initial tour, which are in CrissCross\Scripts\CrissCrossTour.js

CrissCross uses quite a few open-source jQuery plugins and widgits, including:

It does not use any of the ASP.NET AJAX components or the ASP.NET AJAX ScriptManager, sticking instead to jQuery.


CrissCrossLib is the assembly where most of the 'work' happens. And a lot of the work is concerned with dealing with Report Definitions and Parameters.

The namespaces around this area are quite crowded; there's the data structures returned from the SSRS Web Service, and also the similar data structures used by the ReportViewer component. Hence CrissCross's own objects are often prefixed with Crc. For example, CrissCross has a CrcParameterDefinition class, wheres the SSRS web service has ReportParameter as a class, and the ReportViewer has a similar but different ReportParameter class. I'm not usually a fan of three letter prefixes (too reminiscent of Hungarian Notation) but in this case I thought it would be helpful to distinguish the CrissCross classes from the others.

Factory Pattern is used quite a lot - any reasonably complex object has a corresponding Factory that is used to 'make' it. E.g CrcReportDefinition objects are made by a CrcReportDefinitionFactory.

Where sensible, the code uses a very lightweight Dependency Injection pattern. This helps with testing, but I didn't feel I needed the overhead of a full IoC Framework like Castle Windsor. Instead, classes have constructors that allow dependencies to be injected, and then convenience constructors that apply defaults, as described here. Most of the time, there's an obvious default for runtime, but mocks can be injected where necessary by unit tests.

Last edited Sep 2, 2012 at 5:33 PM by codeulike, version 6


No comments yet.