NDepend on a Real Project, Round 1.3: An Exception by Any Other Name...
This is the third in a series of blogs looking at things NDepend told me about a personal project of mine - this time a curious problem with Exception naming.
Practical, Pragmatic Agile
This is the third in a series of blogs looking at things NDepend told me about a personal project of mine - this time a curious problem with Exception naming.
This is the second in a series of blogs about things NDepend told me about a personal project of mine. This time, methods which are apparently never called.
The other day I got an email from Patrick Smacchia, generously offering me an NDepend licence on the grounds that if I find it useful I can write about it on my blog. NDepend allows you to write Linq queries against an assembly or a code base to interrogate it for quality issues and see various metrics and reports. I have a personal project underway which I've been working on for some time, so I figured I'd give it a go and see what it can tell me. This is the first of the results.
AnemicDomainModel is an anti-pattern I seem to keep coming across. Here's an overview of it, the problems it causes, and some pointers on leaving it behind.
I've recently been working with a number of VB6 systems which use C# .NET components via COM, and wanted to keep the same sort of organisational structures and patterns in the C# part of the application as I would if it was a standard MVC app or WCF service - namely, using Dependency Injection to plug the various C# classes together. This is easier said than done with COM, but here's an approach I've used to achieve it.