PrimordialCode

Developing Dexter I encountered again a usual usual error you have to deal with NHibernate and strings: we tried to persist en entity whose string field exceeded the limit imposed by the database table; Nhibernate rightfully complained with:

System.Data.SqlClient.SqlException: String or binary data would be truncated. The statement has been terminated.

Given the fact that having partial data for these fields was acceptable we decided to truncate the value itself. Instead of using the usual solution - that is: take care of this in the entity class or somewhere else during the validation - I decided to build some custom UserType and let NHibernate take care of the truncation if needed (this way we do not have to change anything in the logic of the application).

Why this approach ? well digging into NHibernate code you can see that it uses a lot of structures very similar to a UserType to actually take care of the interaction between the mapped properties and the database (look at the NHibernate.Type namespace in the source code or with Reflector), adding another one isn’t a big issue so I decided to follow their approach and inherited directly from AbstractStringType:

public abstract class AbstractTruncatedStringType : AbstractStringType
{
	internal AbstractTruncatedStringType()
		: base(new StringSqlType())
	{
	}


                
            

In my last post I shown you how to build a simple logging framework for Silverlight applications and use it with an IoC container through ‘constructor injection’, well…in my opinion I consider that a bad programming practice. In short when using a Dependency Injection library you have two types of DI mechanism:

• Constructor Injection: DI through constructor parameters, the DI container try us the constructor that matches best all the modules it knows.
• Property Injection: DI through properties, the DI container try to resolve each property based on the modules it knows.

Usually I use constructor injection for all the modules I consider mandatory and property injection for optional modules. A logging system does not add nor carry any ‘core level’ feature to the application, it’s merely accessorial (even if extremely useful); so a good practice is to not use constructor injection to initialize it, use property injection instead.

Consider something like this:

public class TestLoggingClass
{
 public TestLoggingClass()
 { }


                
            

As your Silverlight projects grow complex you’ll soon start to feel the need to have a solid logging system. In my WPF and Windows Forms project I’m now used to have Castle Windsor + Log4Net as my logging system and I really miss it in my Silverlight applications.

We don’t have a porting of Log4Net in Silverlight yet, but we do have Castle Windsor now. Given the fact I’ll use it in my production environment I decided to roll my version of a simple logging framework that mimic some of the features that Log4Net have and it’s based on Castle Windsor logging capabilities (at first…then if I’ll have the need to switch my IoC/DI framework I can abstract the whole logging system and write the integration facilities).

The goal is to have a simple system that can be configured adding and removing component to the Windsor container.

The logger infrastructure will be like this:

The Logger class derives directly from Castle’s LevelFilteredLogger (which implement the default ILogger interface). The logger also has a collection of appenders, each IAppender object simply exposes a simple Log() function which will accept some parameters and perform the logging operation.

A simple implementation of the IAppender interface is given by the BrowserConsoleAppender class: this class will log the actions to the IE Developer’s Toolbar console script window, or to the Firebug console window.

To simply the logging configuration I’ve added a LoggingFacility class that is able to configure a default application logger or can provide a simple way to configure multiple loggers and appenders if you need a fine grained configuration.

Let’s start simple: in this first version we’ll reuse interfaces and members directly from the Castle namespaces. The IAppender interface will be like this:

/// <summary>
/// interface for our custom appenders
/// </summary>
public interface IAppender
{
	void Log(LoggerLevel loggerLevel, string loggerName, string message, Exception exception);
}

Due to the recent release of Asp.NET MVC2 we’ve decided to port Dexter to the new engine; Ugo spent a couple of days reorganizing the repository and doing the porting (you can read more info on his Italian blog: http://www.tostring.it).

We’ve just fixed some of the bugs that arose after the porting...one them will require some further investigation and will be the subject for a next post :)

If you’re interested in giving a look to the project go to our Codeplex page (http://dexterblogengine.codeplex.com/), I recommend you to perform a fresh checkout to a new directory because many things were relocated.

We’ve switched the developing environment to Visual Studio 2010, if you have troubles in installing Asp.NET MVC2 in your developing machine, you can follow the guideline given in this post: Installing ASP.NET MVC 2 RTM on Visual Studio 2010 RC.

To see the new version of Dexter in action you don’t have to go too far: this blog (and Ugo’s blog too) now runs with the current Trunk version with supports MVC2!

Related Content

• Working on Dexter (26/08/2015)
• More related document (1)

Performing the minification of your custom JavaScript and Css files is usually a good practice to follow when deploying your website in a production environment, but this usually makes doing ‘on the fly’ and ‘live’ modification to those files nearly impossible due to the very compact form they get.

A common technique you can use when it comes to asp.net web sites is to develop an HttpHandler that handle the minification task on the fly.

A very simple approach is to minify each file on a file per file basis, that is: every request of a .js or a .css file will be mapped to be processed by our handlers, the file read and compressed (using an appropriate library) and then stored in the cache (for any subsequent request) and streamed back to the client.

To perform the minification I decided to use the Yahoo! UI Library: YUI Compressor for .Net, but you can change it to whatever compressor you like.

Here’s the code for the Css minification handler:

   public class CssYuiCompressorHandler : IHttpHandler
   {
      private const int DefaultCacheDuration = 30;


                
            

This is a simple tip, I’ve used the Castle Windsor NHibernate Integration Facility to build up the data access services in one of the projects I’m working on, I also wanted to use the NHibernate SchemaExport utilities to build up the database from scratch, this can be very useful when using SQLite in a testing environment.

Since the facility is configured with XML files, I had the problem on how to access the NHibernate.Cfg.Configuration object; having a look at the source code of the Integration Facility it turns out that the Configuration object are registered in the container too along with the factories (one configuration and one factory for each element declared in the configuration file), an alias name is assigned to each configuration object in the form of: {factory_id}.cfg.

So if you have the following settings:

<facility id="nhibernatefacility" isweb="true"
			 type="Castle.Facilities.NHibernateIntegration.NHibernateFacility,Castle.Facilities.NHibernateIntegration">
	<factory id="MainDatabase" alias="nh.facility.default">
		<settings>
			<item key="connection.provider">NHibernate.Connection.DriverConnectionProvider</item>
			...
		</settings>
		<assemblies>
			<assembly>YourAssembly</assembly>
		</assemblies>
	</factory>
</facility>