Tech

Almost everyone who has wandered past the various desks that I’ve occupied over the last year has passed comment on my Wacom Bamboo Pen Graphics Tablet. So, let me say a few words about my experiences with that. For the longest time, I had been perfectly content to use various Logitech VX / MX mouses as my secondary input device, occasionally using a Microsoft Arc Mouse (very convenient to carry around in my rucksack). ...

This dumb mistake just cost me an hour spelunking around in the debugger: var status = source.Substring(source.LastIndexOf("/" + 1)); (where source is e.g. “http://foo.com/status/all-is-good“) Fortunately the ramifications were picked up in the acceptance tests, but the root cause wasn’t at all obvious from such a high level. Lesson for the day – code is never too trivial to warrant unit testing.

This is the fourth in a series of five posts recounting my experiences using Entity Framework Code-First to replace ADO.NET and stored procedures in a client’s existing application. The introductory post in the series is here. I didn’t want this series of posts to descend into a point-scoring NHibernate-versus-Entity Framework comparison, but… I now have a basic proof-of-concept up and running, with my client’s nascent application now being powered by Entity Framework Code-First CTP5 rather than a hand-rolled DAL. So, I had some time to consider future functional and non-functional requirements that the team would be asked to develop and support, and investigate how EF would meet the challenge. ...

This is the third in a series of five posts recounting my experiences using Entity Framework Code-First to replace ADO.NET and stored procedures in a client’s existing application. The introductory post in the series is here. Having configured and initialized Entity Framework, and tweaked the mappings, by Day 3 I was all set to start consuming my shiny new DbContext implementation from the application code, and actually get some CRUD work done. Not unexpectedly, I hit a few issues along the way… ...

This is the second in a series of five posts recounting my experiences using Entity Framework Code-First to replace ADO.NET and stored procedures in a client’s existing application. The introductory post in the series is here. As mentioned in yesterday’s post, I was attempting to use Entity Framework Code-First CTP5 to map an existing domain model to an existing database schema. Fortunately the project was in its infancy and there was a high degree of cohesion between the two models. I therefore didn’t anticipate too many difficulties ahead – the occasional naming discrepancy to resolve, and table-per-hierarchy mappings that would need their discriminators specifying – nothing too complicated really. I hoped to make as few changes as possible to either the database schema or domain model. ...

In February 2011 I found myself doing some contract development work in a team that was still doing data access using raw ADO.NET and stored procedures. Being the NHibernate fanboy that I am, I naturally attempted to persuade them of the benefits of moving over to NH, even going so far as to develop (in my own time) an NH-powered version of their application. My efforts were partially successful. The team were sold on the idea of using an ORM, but wanted me to develop a second proof of concept using Microsoft ADO.NET Entity Framework rather than NHibernate. This prompted much mirth amongst my FaceBook friends. ...

Having slain the beast that is Shared Database, the next dragon to appear on my Enterprise Integration horizon is Shared Assemblies. That is, the suggestion that Application A can leverage the functionality of Application B by simply adding references to B’s DLLs. After all, this potential for reuse is why we put our code in reusable assemblies in the first place, isn’t it..?! Well, no. Actually we usually break our application apart into assemblies to create a maintainable and testable architecture. An assembly is a coarse-grained unit of encapsulated functionality in that architecture; the fact that it is the smallest deployable unit in the .NET world is not necessarily an indication that we intend or desire our assemblies to be shared with other applications. ...

A few days ago a friend emailed me the following question regarding NHibernate mappings for a solution he’s currently developing: “I have an idea entity that has a collection of comment entities and I need to get the comment count for each idea. I made a massive mistake at the beginning by calling idea.Comments.Count (even worse, I did it in the view!), which due to the collection being lazy-loaded caused about 10 database calls so performance was sluggish even with second level cache. I was therefore wondering how you would do it – would you use HQL and use Comments.size or would you do something differently?” ...

So, I was in the office at a client site, walking back to my desk after grabbing a quick coffee, when a developer on a sister product to my current project grabbed me and asked (I paraphrase somewhat): “Hey, Ian – [my app] needs to retrieve [small piece of data] from [your app], so I’ve stuck a stored proc in [your database], OK?” I felt quite violated. My poor app, what had it done to deserve this despicable treatment? ...

I just had an email from a friend asking where business logic should go when using MVC – the controller or the model. I thought I’d share my reply: I think asking whether the business logic should go in the Model or the Controller is a false dichotomy. There are different kinds of business logic, and there’s also the possibility of putting it somewhere else entirely. Much business logic does indeed belong in the model, particularly stuff like encapsulating calculations and projections, adding meaning to raw data properties, and ensuring domain objects are maintained in a valid state. I see this as the traditional side of OO design – encapsulating logic and restricting accessibility. ...

When I first started writing automated unit tests for my code, I remember getting carried away writing lots of tiny little tests, each with a single Assert. It felt good initially to see all those green ticks, but rapidly became a maintenance headache, and I am now happier having fewer less-brittle tests that do more. I think it’s great when tools like AutoMapper provide powerful methods like… …allowing me to test large swathes of the system configuration with a single, stable test. ...

I’ve been asked “How do you test LINQ queries?” a couple of times in the past few months, so I thought I’d blog my answer for the benefit of all you lovely people. Firstly I should explain how I’ve been doing most of my data access in recent months. I find that the Repository pattern, and particularly the .NET implementation described here by Fabio Maulo meets the vast majority of requirements I have in my applications, and I fall back on additionally using custom DAOs when required. ...

I’ve done a fair bit of WCF development recently (and amazingly I came out of it relatively unscathed, both psychologically and emotionally). Using Castle Windsor’s WCF Facility helped a great deal, but I still found myself writing a fair bit of infrastructure and plumbing code. I thought I’d blog some of these code snippets lest I forget, and on the offchance they might help others. One of the things I wanted to achieve was to ensure that any unhandled exceptions that propagated to the top of the stack were logged. The following custom EndpointBehavior achieves that. I’m using Castle Logging Facility here, but you could of course swap out the logging code for whatever error handling code you require. ...

Here’s another custom WCF EndpointBehavior I found useful recently. Not content with logging all unhandled errors, I wanted to output a DEBUG level log message before and after every operation invocation. As before, I’m using the Castle Windsor Logging Facility to handle my logging, but you can swap that out for your logger of choice if required. Firstly, here’s the EndPointBehaviour itself. This adds a custom CallContextInitializer to every service operation: ...

OK, my last WCF-related code snippet of the day, I promise. This is quite similar to the last one. I required that the WCF service I was developing started a new NHibernate Session for each invocation, and closed it after invocation (i.e. session-per-request). I couldn’t rely on the ASP.NET session start and end events in global.asax as this particular WCF service was to respond to MSMQ messages rather than HTTP. ...