The Evils of Shared Check Out

I won’t discuss the obvious what-do-you-do-when-somebody-else-checked-in-before-you-and-now-you’ve-ended-up-resolving-the-conflicts. I think there are more subtle motives why the version control shared check out has negative impact on modern software development.

I believe that the shared check out feature of most source control system (svn, cvs, tfs) originated in a time when developers worked on huge code files, when solving one bug meant making adjustments in more than one of these monstrosities at the same moment. In a time of stone age development tools, when modern programming concepts like OOP and FP were in still in the realm of academia and of obscure languages.

The tools and languages evolved, but the way they were used had its own inertia, based on human habit and familiarity with a way of “doing things”. Forget about one class - one concern, some people are still struggling with one function – one concern.

The conclusion is that if you are aware of a couple of development techniques, there will be no need for shared check out. One class should be modified for only one reason, so two people don’t have to edit it at the same time.

Of course there are counter examples. I already hear people shouting “configuration files”, “generated code files” etc. Those are exceptions and at the same time, they are not. If you’re willing to break the structure into small, manageable parts, you’ll find a solution for them. And if you really need to store many things into one file, be sure to set rules for how people should edit it, so they know how to not get into trouble. This is a similar problem to using only pure functional programming. FP is great, but you’ll need to modify state sometime: make sure you’re doing it in a standard, isolated way, so when a problem arises you’ll know what you’re dealing with.

Why You Should Write Your Own O/R Mapper ... Or At Least Try

Because you will not use it. But in the process you'll probably learn a lot of things about what a data access layer is. And more important, you'll be able to judge the existing O/R mappers and chose the one that fits most of your needs.

The down side is that the period of time before you choose to "upgrade" to an already existing solution will seem a waste, and all the code you've written must be thrown away. That won't be an issue if you keep in mind that things are replaceable and if you build a loosely coupled designed so components, like the data access layer, can be replaced, almost, effortless.

This pattern applies to other general "patterns", like dependency injection containers. Hands on experience with their "entrails" should give you a better understanding of how they work, and a better appreciation of the ones that are already available. And chances are you've already tried to build something similar but never knew exactly what you wanted, or what the big picture of the solution is.

Nice Design Example for a Simple Data Access Layer

If you are in the process of implementing a small data centric application, you'll probably need to write some data access code. I've recently stumbled upon Los Techies, which is a wonderful resource for good programming practices. I especially enjoyed Jimmy Bogard's series on the problem of separation of concerns.

The series is centered towards refactoring an existing solution to a better design, employing well known patterns and practices. But the interesting part is that at the end the result is a nice blue print for a general data access layer based on Linq. And a really good start point if you're trying to build one.

Below are links for the six parts of the series:
Separation of Concerns - how not to do it
Separation of Concerns by example: Part 1
Separation of Concerns by example: Part 2
Separation of Concerns by example: Part 3
Separation of Concerns by example: Part 4
Separation of Concerns by example: Part 5

Linq to SQL Server CE and uniqueidentifier columns

There will be a couple of issues if you you try to use linq to sql with a SQL Server CE database. First of all the VS2008 designer doesn't allow adding tables from this type of database. The solution is to use the SqlMetal command line tool in order to generate the dbml or the code file (see here).

The second issue is that uniqueidentifier columns with the rowguid property will not work. More precisely, they will not autogenerate a value upon inserting a new row. Setting the column property to IsDbGenerated in the dbml mapping file is even worst: it will crash the insert operation. There is a workaround for this problem: in the partial class of the respective table entity, create the partial method "OnCreate" and manually set a new Guid for the new record:

partial void OnCreated()
{
    if (ID == Guid.Empty) ID = Guid.NewGuid();
}