Development Practices

StructureMap: Part 4 - Scanning

Index Part 0 – Introduction Part 1 – The Basics Part 2 – Instance Lifecycles Part 3 – Constructing the Concrete Type Part 4 - Scanning So far I’ve shown enough to build a working DI system. By registering concrete types for your abstractions you can fully configure the container. However it’s unlikely to have escaped your notice that doing...

posted @ Saturday, July 03, 2010 11:43 AM | Feedback (0)

StructureMap: Part 3 – Constructing the Concrete Type

Index Part 0 – Introduction Part 1 – The Basics Part 2 – Instance Lifecycles Part 3 – Constructing the Concrete Type Part 4 - Scanning Now that we can control the lifecycle of an instance it’s worth considering how those instances are constructed. In the code shown so far the parameter-less Use method is responsible for specifying the concrete...

posted @ Friday, June 18, 2010 12:53 AM | Feedback (0)

StructureMap: Part 1 – The Basics

Index Part 0 – Introduction Part 1 – The Basics Part 2 – Instance Lifecycles Part 3 – Constructing the Concrete Type Part 4 - Scanning Let’s start at the beginning which is allegedly a very good place to start. Before StructureMap can construct any kind of concrete type for you it must be told what it should construct. StructureMap...

posted @ Saturday, June 12, 2010 11:26 PM | Feedback (1)

On the naming of classes with similar purposes in different contexts

It’s not uncommon in an application to have different representations of the same concept in different contexts. For instance you may have a concept encoded as a domain object and also as a type in a message contract. In this case you will generally want to use the same name in each context. However this has the disadvantage that the class name is now somewhat ambiguous. In such cases there will likely be at least one place in the code where you will need to refer to both contexts. This necessitates a mechanism for distinguishing between the types from...

posted @ Tuesday, March 16, 2010 9:18 PM | Feedback (0)

Upfront Database Design Is Evil and Foolish

A practice that I occasionally encounter is having the database to be used by a system entirely “designed” upfront before development starts. This practice implies that the data structure an application requires may be anticipated before the code is developed. Practical experience shows this view to be at best naive. Attempting to fully anticipate the needs of a system upfront is an exercise in futility. Any business system complex enough to be worth considering as a project will have facets that only become apparent as the system is constructed. Additionally as a development team works with a problem domain...

posted @ Tuesday, March 16, 2010 9:17 PM | Feedback (0)

Locating your project tooling

Many development projects rely on tools in addition to standard integrated development environments. How these tools are managed can have a significant impact on the maintainability of the project. Problems can occur when different development environments are using different versions of tools, or when tools are assumed available but not present in some environments. This can also be an issue between different branches in the same environment when tools or tool versions change. It’s unfortunately common for developers to rely on tools being installed in an environment. This makes changing the tool version problematic as the change must be...

posted @ Wednesday, February 17, 2010 11:42 PM | Feedback (0)

Boy scouts on amphetamines

Disclaimer: No boy scouts were harmed in the production of this post The Boy Scout Rule is in my opinion a highly valuable mechanism for ensuring that a code base remains effective over time. The Boy Scouts of America have the rule “Leave the campground cleaner than you found it.”* Applying this to the code as it is maintained provides an efficient mechanism for ensuring code quality. The marginal effort required is relatively low as you are already working with it and hence the effort to understand the purpose and structure of the code is...

posted @ Sunday, December 27, 2009 2:03 PM | Feedback (0)

I have more test code than solution code, and that’s OK

Looking at a personal project I’m doing at the moment I see that in terms of lines of code some of my test projects are significantly larger (up to 2.5 times in this system) than the projects they are testing. This seems like a large amount of overhead but a less superficial analysis shows that this really isn’t a negative. Looking at the code itself it becomes apparent that the test code is significantly more straightforward that the code it tests. My test code contains no conditional statements and will have only a single path of execution. Each test...

posted @ Friday, December 18, 2009 11:04 PM | Feedback (0)

What’s good in .NET?

Lest my previous post is interpreted as my not liking the .NET platform, here’s a collection of things that are great (and which you will have to prise from my cold dead fingers). Lambdas, Extension Methods and the Enumerable and Queryable classes. How did we ever live without them? ReSharper. Visual Studio is merely my ReSharper hosting environment. Please JetBrains, write a .NET IDE. TestDriven.NET. So much faster than anything else out there for running unit tests. Does one thing, does it amazingly well. Gallio and MbUnit....

posted @ Sunday, December 13, 2009 3:45 PM | Feedback (0)

In which I rant about how Microsoft views developers

Disclaimer: Microsoft is a large and heterogeneous company and these comments will not necessarily apply to all of the organisation. I’ve just read a blog post by a Microsoft Software Engineer that represents what I believe is the fundamental problem with how Microsoft views the developers who use their tools and APIs. Here are the two key quotes: “We sit around the table designing APIs, and for the most part unless we have time to actually think through the extensibility/usage scenarios and ensure they’re safe or at least make some sense,...

posted @ Sunday, December 13, 2009 2:53 PM | Feedback (2)

‘as’ is no safer than cast without a null check

I’ve recently encountered code which looks something like: var someInstance = someParameter as ISomething; someInstance.DoSomething();   The problem with this code is that it is wide open for a highly unhelpful NullReferenceException. If someParameter cannot be cast to ISomething the as operator will return null. But this code doesn’t check if someInstance is null. It makes the assumption that someParameter may be case to ISomething, even though in practice this assumption may not hold. There are two solutions to this. You may replace the use of the as operator with an explicit cast. This will throw an InvalidCastException if the cast cannot be...

posted @ Tuesday, November 03, 2009 3:44 PM | Feedback (2)

A small example of the value of separation of concerns

In a recent project I’ve had to implement a feature I think is a good example of a separation of concerns at a small scale. This feature involves giving the user a choice from a set of items. The available items from which the user may select an option is determined by a couple of factors. First there is a pool from which they may draw items. Users will preferentially get only those items directly associated with themselves if any are available. If no items are associated with the user then they get those associated with their user class....

posted @ Saturday, August 15, 2009 3:35 PM | Feedback (0)

Simple organisational improvements: Remember the alphabet

Software contains many examples where a number of named items must be listed in a context where the order is not important. This is particularly prevalent in configuration files but is also found in code. One example I’m currently looking at is a set of WCF service host classes that need to be run in a service. The order they start is irrelevant as long as they are all started. As there are a number of types it’d be nice if I didn’t have to scan the list every time I wanted to see if something was included. This...

posted @ Wednesday, July 22, 2009 2:37 PM | Feedback (0)

On the addressing of pain points

One of the criteria I have for separating true software developers from the hack and slash crowd is how someone goes about addressing the deficiencies and inefficiencies in their project. A project with a real software developer will see the number of pain points decrease over time, leading to higher efficiency and an easier to work with system. So what is a pain point? I define a pain point as any element of the system or its development environment that is unnecessarily complex, time-consuming or fragile. Pain points are the things that get between the development team and the...

posted @ Wednesday, July 22, 2009 12:43 AM | Feedback (0)

Clean the shared state your test uses before it runs

It is an unfortunate reality that it is not feasible to isolate your code from all shared state. Although the use of repositories, wrappers and similar can be used to provide decoupling their user is not always feasible. It is also desirable to test the implementation of the code providing the decoupling which will force us to work with the shared state. From a unit testing perspective shared state may be anything mutable that is visible between the execution of any two tests. This can include static properties, call context, relational databases and file contents. It may also include...

posted @ Tuesday, July 21, 2009 11:13 PM | Feedback (0)

Providing configuration via injected interfaces

Configuration is an important part of most large scale applications. It’s also a distinct concern the details of which we wish to hide from the rest of our system. I address this by defining an interface that provides the configuration values. By using such an interface we break the coupling between the configuration system and the rest of the system and enabled some more interesting scenarios. In a standard case you may have a configuration section and some configuration elements. In my example we define some interfaces: public interface IExampleConfiguration { IExampleComponent ConfigurationComponent { get; } ...

posted @ Saturday, July 18, 2009 1:14 AM | Feedback (0)

Repositories in LINQ-to-SQL

I’ve recently been working with LINQ-to-SQL as the ORM for a project. Although not my preferred choice I’ve been looking at the best ways I can apply the technology within the bounds of the project. In this case this means applying the Repository pattern. In this context the primary need for the repository was to break the direct link between the LINQ-to-SQL context and the business logic so that the business logic could be relatively independent of the database and could be tested in isolation. The business logic does tend to have queries in it which could be separated...

posted @ Wednesday, July 15, 2009 11:41 AM | Feedback (2)

The database is a bit bucket

I’m known to hold Views (with an explicit capital) on the development of enterprise application software. Today’s post covers my View of the role and application or RDBMSes in enterprise applications and is summarised by the post title: I hold that the database is a bit bucket for the application and that it is mistaken to expand its responsibility beyond this. By bit bucket I mean that the database is the container for the application’s data. It is responsible for the key concerns of storage, organisation and access of this data in a performant and transactional fashion. These are...

posted @ Saturday, July 11, 2009 3:20 PM | Feedback (0)

“Die Hippie Scum” and other things not to put into production code

Tonight I attended the Perth ALT.NET group and wrote part of the code in the Domain Driven Design Dojo (DDDD). As this code was to illustrate DDD principals only and never intended for production it exhibited a number of properties that real production code should not. This included little validation, static global types to supply dependencies and a repository that was backed by an in-memory collection. One notable piece was the InvalidOperationException I had the code throw on one particularly significant error. This had the highly informative message of “Die Hippie Scum”. This is not the type of message that...

posted @ Friday, July 10, 2009 12:48 AM | Feedback (1)

Applicability of the various methods for creating type instances

My previous post discusses the use of interfaces and base classes to break coupling between c lasses. Although it touches on it briefly it does not discuss in depth the creation of instances. This is an important topic in its own right. Done incorrectly you will get no decrease in coupling between classes. However there is not a single approach that is applicable to all type categories within a single application and the requirement to eliminate coupling likewise varies between these categories. From the perspective of instantiation we can consider types to be organised into a number of key...

posted @ Friday, July 10, 2009 12:32 AM | Feedback (0)

Full Development Practices Archive