Subscribe: Jimmy Nilsson's weblog
Added By: Feedage Forager Feedage Grade C rated
Language: English
blog  called  code  design  domain model  domain  don  good  interesting  might  model  net  new  patterns  tdd  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Jimmy Nilsson's weblog

Jimmy Nilsson's weblog

Published: Mon, 07 Mar 2005 22:00 +0100

Copyright: Copyright 2004 by Jimmy Nilsson

Tools and skills

Tue, 21 Dec 2004 23:02 +0100

I've often been asked something like this:
"My crew is really good at SQL and stuff like that... and writing DALs... Why on earth should we move to OR Mapping?"

At first I didn't know what I should say... "Do what you are good at" was my spontaneous answer.
But the paradox here is that I also come from an SQL background and I still find OR Mapping a very interesting tool in many situations. So my conclusion is that I definitely don't think that using OR Mapping is a waste of SQL skills. Being skilled in SQL is a huge advantage if you want to become good at using OR Mapping. OR Mapping is a way of getting more productive, not primarily about *hiding*! (Well, I think it's primarily an enabler, but that's another topic.)

This is just one more example to add to those I mentioned in the blog post "Tools and teeth".

Oh, one more thing. A vendor once told me that any beginner would beat any old fox if they used their tool... No way! As soon as there is the slightest problem... You get the picture.

Don, Ted and Tim

Tue, 21 Dec 2004 23:01 +0100

It's been a couple of weeks since I listened to this .NET Rocks episode with Don Box, Ted Neward and Mark Pollack. Anyway, I'd like to write a few comments.

As I recall, among other things Don said something along the lines of "OO is done". Well, I agree that OO is more mature now than it was a few years ago, but I still think there are loads of things that haven't been settled... and loads of developers still haven't even begun the journey at all. When I listen to Don these days, I sometimes get the feeling that the only abstraction anyone will ever need again is "message". Don, was that provocative enough?

Anyway, in my opinion SOA is definitely interesting *too* and I hope to learn a lot at the Indigo day at VSLive in San Francisco in February.

In the same .NET Rocks episode, Ted Neward was pretty critical to OR Mapping, but in the end said that mappers work for x% of the situations, and that's perfectly in line with my viewpoint too! I mean, every tool can be terribly misused.

Tim Ewald wasn't on that .NET Rocks episode, but he said something very interesting here. One of the things he said about objects being a good implementation technique for services was "In general, you want an internal object model that you use to implement your core logic."

Tim hasn't become famous for being pro-Domain Model so I thought this was an interesting comment.


Tue, 21 Dec 2004 23:00 +0100

As I've said before on this blog, things are really happening in IT-Sweden! Sooo much is going on and the latest sign of this is that another user group has been formed. It's called SQLUG.SE and is a Swedish user group for people interested in SQL Server.

The founders are Tibor Karaszi, Tobias Thernström and myself.

Go here:

NWorkspace and DDD

Thu, 16 Dec 2004 00:40 +0100

Tap, tap... Anyone there?

Today I'd like to show you how I use NWorkspace in a DDD-inspired design. Here I have a repository for each aggregate, therefore, there's a repository called CustomerRepository, for example.

The CustomerRepository will get an IWorkspaceForRepositories in the constructor. This interface is just like IWorkspace, except that it doesn't contain PersistAll() or Clean(). The idea is that the consumer (such as an Application layer or even the presentation layer directly) will coordinate the complete session and consequently doesn't want the repositories to interfere. Therefore, PersistAll() and Clean() will be done by the consumer (via the IWorkspace).

OK, let's repeat part of what I have shown in previous blogposts here and here, but this time with repositories involved. The changes are marked in bold.

//--Instantiation of workspace.
private IWorkspace _ws = new WorkspaceNH(_sessionFactory);
//Here the repository gets the _ws as an IWorkspaceForRepositories.
private CustomerRepository _r = new CustomerRepository(_ws);

//--Insert of an instance.
Customer c = new Customer();
//...Do stuff with Customer...

//--Reconstitution of an instance.
Customer c = _r.GetOrderById(42);
//instead of this:
//Customer c = (Customer)_ws.GetById(typeof(Customer), 42);

IList aCustomerList = _r.GetOrdersByName("Volvo");
//instead of this:
//NWorkspace.IQuery q = new Query(typeof(Customer));
//q.AddCriterion(new Criterion("Name", Operator.Equal, "Volvo"));
//IList aCustomerList = _ws.GetByQuery(q);

//... or set up query and call:
IList aCustomerList = _r.GetOrdersByQuery(q);

//... and if it's a typesafe list, that's "hidden" by the repository, for example, like this:
CustomerList aCustomerList = _r.GetOrdersByQuery(q);
//instead of this:
//CustomerList aCustomerList = new CustomerList();
//_ws.GetByQuery(q, aCustomerList);

It's important to note that I still think that the Unit of Work and Identity Map should typically "span" several repositories and therefore be controlled by the consumer instead of by the repositories.

To summarize the differences when using DDD (on a micro level like the API above), the querying becomes very simple. You can decide yourself whether you want the repositories to use the querying API for defining the queries or whether you want the consumer to define the queries and just ask the repositories to execute them (depending upon the situation). That's more or less it. The most interesting things with DDD are more on a macro level, but this a completely different topic. Here I just wanted to show how you *can* integrate NWorkspace with a DDD-ish design.


NWorkspace, tx API

Wed, 15 Dec 2004 07:10 +0100

When I first started discussing NWorkspace at SwedArch, the most common comment I received was that it lacked an interface for explicit transactions. I might add this later, but for now I'm trying to keep the requirements down as much as possible in order to create something very simple, yet useful. It's a balancing act and I'm not sure I have found it yet. Anyway, here goes.

When you do a _ws.PersistAll(), it will always be wrapped in a transaction behind the scenes. If there is a problem, there will be a rollback. This happens even if you have only one dirty object. First of all, it's simpler that way and the overhead is most likely very low. What might also happen is that the mapping for the class is to two different tables. So when you think you are updating only one table (because it was just one class), in reality it might be two updates, and an explicit transaction is necessary as otherwise it would become two implicit transactions (and this is especially troublesome if over time the mapping is changed from one table to two tables.)

That was about INSERT, UPDATE and DELETE. When using GetById() and GetByQuery(), SELECTs are used. By default SELECTs will not get an explicit transaction in NWorkspace, but will execute in their own implicit transactions. The exception to this rule is if you want to hold on to readlocks until PersistAll(). In this case you have to say BeginReadTransaction() before you start reading, and send a transaction isolation level as argument.

Another thing that is supported (only after BeginReadTransaction()) is using an overload to GetById() and GetByQuery() to say that you want to get "exclusive locks" for those situations when you would otherwise risk getting a conversion deadlock. This should be used with care, of course.

Finally, if you want to forget about all the changes you have done, without persisting them to the database with PersistAll(), you call Clean().

I think that's it for the moment. Comments?

NWorkspace, querying API

Tue, 14 Dec 2004 12:00 +0100

OK, here I talked about the basic idea, and here I talked about the basic API, except for querying. It's now time to deal with querying.

My idea is that the NWorkspace assembly provides an interface called IQuery and a simple implementation of that interface called Query. You can use Query directly if you want to for, say, fetching all the customers with the name Volvo (OK, there'll probably only be just the one, but that's not important here):

NWorkspace.IQuery q = new Query(typeof(Customer));
q.AddCriterion(new Criterion("Name", Operator.Equal, "Volvo"));
IList aCustomerList = _ws.GetByQuery(q);

Here is an alternative for the last line above, if you prefer working with type safe lists:

CustomerList aCustomerList = new CustomerList();
_ws.GetByQuery(q, aCustomerList);

I could say more about, say, sorting, but I think you get the picture.

It's also possible to wrap the Query class in a custom query class in the Domain Model. (Of course you could skip wrapping Query and provide your own implementation of IQuery.) I think it's a nice solution to add a library of type safe queries to the Domain Model. Doing this would mean that the API for the consumer would become easier to use, for example. This is how the query could look like with a custom CustomerQuery:

CustomerQuery q = new CustomerQuery();
IList aCustomerList = _ws.GetByQuery(q);

OK, this simple example was not a big deal, but in real situations if you create custom queries you can provide lots of power to the consumers and a very simple API at the same time. You also have the query definitions where I think they belong the most, being in the Domain Model, and they are (to a large degree) transparent to the OR Mapper that is used.

Yep, in a way the whole NWorkspace API will be the least common denominator. Saying that, I won't start the design by investigating what the different mappers can do. Instead I will just create a simple API that I want to have for dealing with the most common situations. Then, if you need power, you always have the possibility to go directly to the mapper. You should, of course, try to avoid that if you have decided to use a higher-level abstraction. However, when you do need to you can, just as you can skip the OR Mapper (for most mappers) and go directly to SQL when you really need to.


NWorkspace, basic API

Mon, 13 Dec 2004 22:12 +0100

OK, if you're going to get a feeling of what I'm talking about when I refer to NWorkspace here I think we need some examples. So, I'd like to show some code for what it could look like when working with NWorkspace from a consumer perspective. If you have seen Valhalla before, you'll probably feel pretty familiar with the basic API.

Please note that I'm leaving out repositories here so as not to distract you from the NWorkspace API. Of course, repositories aren't a necessity, they are just something I happen to like.

For the sake of the example, imagine an adapter implementation of NWorkspace called NWorkspaceNH which transforms from NWorkspace to NHibernate. OK, let's get going.

//--Instantiation of workspace.
//Note that _sessionFactory is an ISessionFactory from
//NHibernate and has been set up before the following line...
//Also note that this is the only variation depending upon
//the adapter implementation.
private IWorkspace _ws = new WorkspaceNH(_sessionFactory);

//--Insert of an instance.
Customer c = new Customer();
//...Do stuff with customer...
//Add() below means "associate" this instance with the Unit of
//Work and decide if INSERT or UPDATE is needed.

//--Reconstitution of an instance.
Customer c = (Customer)_ws.GetById(typeof(Customer), 42);

//--Update of a customer.
//...Do stuff with customer...
//Associate if unknown to Unit of Work...

//--Explicit start of transaction.
//IWorkspace.PersistAll() is always wrapped in a tx,
//but if you want to hold on to readlocks until PersistAll()...

I skipped the querying part as this blog post is already too long as it is. You'll find the querying API proposal in the next blog post in a few days' time.


DDD and DataSets

Thu, 09 Dec 2004 23:03 +0100

I'm just back in my office again after having given my course, "Patterns with .NET". I love giving this course, and it was just as much fun as usual (if not more) this time. One thing I particularly like is that I always get so many interesting ideas from the participants.

For instance, this time two participants, Ellen Lippe and Atle Haugan from Trondheim in Norway, asked me if they could reuse any of the DDD concepts I had been talking about when they use DataSets. I honestly hadn't thought about it in this way before, since I have mostly seen DDD as a way of structuring a Domain Model [Fowler PoEAA]. After a while they helped me to understand that in some cases combining DDD and DataSets might be a good compromise. For instance, a DDD Aggregate could be structured as a Table Module [Fowler PoEAA] wrapping a DataSet. The repositories could deal with the lifecycle of these aggregates too, and so on.

I think we agreed that it is a bit unnatural in some situations, but life is full of compromises, and, depending upon the situation, this might a very good one!


Thu, 09 Dec 2004 23:02 +0100

My session (in Swedish) about TDD is up on MSDN TV now. You find it here.

Well, what can I say? My throat was giving me grief, and it was my first time in a studio, and...


Thu, 09 Dec 2004 23:01 +0100

There is a recently started architecture-focused forum called SwedArch and already there are lots of lively discussions taking place. Unfortunately (or not, depending upon your language skills), it's only in Swedish.

Go here.

NWorkspace, why

Thu, 09 Dec 2004 23:00 +0100

My current pet project is called NWorkspace and is (or, at least, might become) what I call adapters for different persistence solutions. Nope, it's *not* another OR Mapper for .NET, which might come as a shock! :-) Instead, what NWorkspace does is try to reuse the functionality of the current OR Mappers. Pretty wild, huh? First of all, let's take a step back. As you might have noticed, if you are following my blog, I'm currently working on a couple of DDD projects. What I have noticed is that I find myself writing some silly code purely to be able to run automatic tests against a stub which simulates the database and against the real database (when it has been built). Sure, I know, I can run the majority of tests against the Domain Model without dealing with persistence at all. I do that, and that's not the problem here. The problem is when I take the next step, so to speak, and want to test the interaction where repositories are involved. What also happens is that I want to let users try out the application before the database has even been created. What they get instead is just a stub, so that they can get a feel for the application and provide feedback early on. This allows me (and the team) to make pretty radical changes to the Domain Model and UI without having to make any changes to a database schema as well. It's also extremely easy when it comes to distribution and installation for early demos. You may be wondering what this stupid code is. Well, assume I use a custom stub for tests without database, and NHibernate for example as the OR Mapper for tests with the database. Typically, what I do then is create a specific interface for each repository, such as ICustomerRepository, for example, which I implement by the classes CustomerRepositoryStub and CustomerRepository. The code in those classes is pretty similar but different, so I need two of them. They get information from the consumer as a constructor parameter, such as a stub instance, in the case of the stub implementation, and an ISession, in the case of NHibernate. The CustomerRepository can then use the ISession for stating database questions and for associating instances with the Unit of Work. When it comes to the CustomerRepositoryStub, there is no database against which to ask questions, so the stub-repository will iterate lists for filtering out the requested instances instead. Pretty different, as I said. What also happens is that this affects the test code. It's not just how the instantiation of the repositories is done that differs, but how the transaction is dealt with, etc. So, what I usually get is three test classes (one is a base class) per repository, one repository interface and two repositories (in two separate assemblies). Not an extreme amount, perhaps, but it doesn't feel too good. So, I started thinking about how hard it would be to create some abstraction for which I could create implementations for different persistence providers. This would mean that I could code against that abstraction in both the tests and the repositories, and in doing so reduce the amount of dumb code. I could probably see the NH-interface as that abstraction and let the stub implement it, or I could implement a stub dialect for NH... However, I thought this might be a generic problem for several OR Mappers that I would be working with, so I started another route. That's where NWorkspace comes in. So, NWorkspace is mainly a couple of simple interfaces (and some helpers), which are implemented by adapters so that NHibernate can be used under the surface. Or my stub implementation, or probably many other OR Mappers as well, if adapters are written for them. However, please note that I don't think this will be used for switching[...]

Wanna bet?

Thu, 18 Nov 2004 21:30 +0100

I'm not a gambling man, I never play the lottery or anything, and especially not after a friend said that "lottery is extra tax for people who are having trouble with math".
However, I'm going against the grain today.

Here's a bet. I bet that the PAG group at MS will skip the current "silver bullet" and give recommendations about how to apply DDD (or similar) when MS have products that provide reasonable infrastructural support for rich Domain Models. I'm thinking about, say, ObjectSpaces or something else that deals with the same kind of problems.

Please note that I'm NOT saying that DDD is the silver bullet either (- no way!) but I do think it's an interesting tool for the toolbox.

I also bet that a lot of the guys in the PAG group would like to give recommendations like these today or even sooner, but it's probably not a techie decision not to.

Wanna bet?

A fun week in Stockholm

Mon, 15 Nov 2004 23:20 +0100

Last week I spent a few days in Stockholm and I felt like writing a few words about it. It feels like things are cooking in .NET land in Sweden. Sooo much is going on. Or perhaps that goes for the whole system development arena nowadays. Anyway, here goes.

  • I gave my course (Patterns with .NET) in a packed room Monday to Wednesday and it was great fun! It occurred to me that I always have such smart, skilled and interested participants and it was just the same this time! Ah, perhaps I can deduce that smart people are attracted to my course?

  • On Wednesday evening, I talked about "Best practices for accessing data in .NET" at SweNug. Again, very skilled, smart and interested people! And I got to meet Johan Lindfors at Microsoft for the first time. He's not only smart, he is also the kind of guy who gets so much done! NO "all talk and no action" there!

  • Thursday morning I was supposed to record a session for MSDN TV, but my throat was playing up. It almost never gives me any problems, but the evening before I had a beer with Mats Helander (OK, OK, perhaps two) and it was a little smoky in the pub. I've become extremely sensitive to smoke in the last few years... Anyway, I hope I managed to do my bit well enough. We'll see in a few weeks I guess.
    It was a fun experience and I think I learned a lot, so I hope I get a chance to do it again some time.

  • Thursday afternoon I gave a presentation about TDD at Windows Technology Forum. It was great, especially because of the interesting interaction with the audience. Again the audience was... you get the picture.

  • Finally, on Thursday evening I went along with Mats to his new employers for a members' meeting with .NetAkademin. I got the chance to listen to a great presentation by Johan Lindfors and chatted over dinner with several people from .NetAkademin such as Lena Larsson and Henry Aspenryd. Thanks a lot for your hospitality!
Yep, it was a great week! Now I'm back to normal, and I like that too of course. Time to catch up with the backlog.

Doc to db

Mon, 15 Nov 2004 23:15 +0100

As some of you might have noticed, I'm pretty fond of Domain Model-focused design (DDD, or whatever you call it) nowadays.

Even so, I'm also very interested in SO, for example. I mean, I think it's important to keep an open mind, and try to make sense of different approaches according to the situation. When I'm in a really wild mood I even think it might make sense to combine several approaches!

That's the reason why I want to get a better understanding of what Andres is talking about here and Mats here. Let's call it "doc to db". I think I understand the overview (at least well enough to believe it's interesting and that I want to learn more), but Andres doesn't agree...

Here are some unordered questions for Andres and Mats - and anyone else, of course.

  • The borders of the docs will be static, right? Could that become a problem for flexibility?

  • Do you envision overlapping docs or not?

  • Would you recommend the solution for in-proc situations too?

  • Do you see any drawbacks with behavior-less classes?

  • Will there be many places to change if there is a change in the database? Or do you envision some central model which will be the only place to change? If so, how do you envision the implementation of that model?

  • There won't be anything like an Identity Map or a Unit of Work across several docs, right?

  • How is this better than DataSets? How is it worse?

  • If the client's platform is unknown, what to give the client then? Validation stuff anyway? If so, in what format?

  • How do we ask for a certain doc? By an enum (or similar) parameter? Or many fine grained services so the client can aggregate the doc by itself? Or only a few coarse grained services?

  • Regarding global rules (rules that require more than a single doc), will they go to the database? Or to a global doc? Or to what?

  • Would you agree if I say that a doc sounds similar to what Martin Fowler talks about in the Presentation Model pattern?

NHibernate and COMB

Mon, 15 Nov 2004 23:10 +0100

Not that it's very important, but I noticed that NHibernate version has a built-in generator for COMBs. It's called guid.comb.

Interesting times

Wed, 03 Nov 2004 20:55 +0100

I have been lucky enough to have as much work as I can handle over the last few dark years. Now it seems as if these years have come to an end. Last week, I had a bizarre Wednesday. Before lunch I received three completely new, unrelated prospects, and one old one that was brought back to life again. Then, in the afternoon there was yet another new prospect. This might not sound much to you, but it hasn't happened to me before and I have been running my company for twelve years now.

What? You don't think this counts as evidence for good times to come? OK, OK, it's a coincidence, of course, but a nice one.
My guess is that it will be hotter than ever this time. Perhaps not 'crazy-hot' like last time, but 'different-hot'.

Oh, and at the same time, universities are still reporting (at least in Sweden) that they are no longer getting any students for the software development programs. Yesterday the local newspaper said that the number of students has decreased by 50% in Sweden this year, and this is from an already extremely low number...

A favor to mankind

Mon, 25 Oct 2004 21:01 +0100

Dan says I forced him into blogging. I'm happy I did, I think it was a favor to mankind!
UI programming isn't my scene at all, but this blog post almost made me think again.

Anything new on AOP in .NET land?

Mon, 25 Oct 2004 21:00 +0100

As you might remember, I have blogged about AOP in .NET earlier (here, here, and here). I guess it's time for an update.

This summer I saw that Eric Gunnerson from the C#-team blogged about AOP here. As I said, this post is a few months old and Eric is no longer with the C#-team, but even so, the conclusion I draw from the post is that we won't be seeing any AOP support in C# in the near future...

I heard that Anders Hejlsberg received many requests from developers to extend the semantics of partial classes in .NET 2.0. I'm actually one of them. We discussed whether making it possible to use a fragment of code in several classes, by slightly extending the partial classes feature, would be a good thing. It would be like poor man's AOP Introduction - static, but fine for now, especially with some editor support. Adding an aspect in the form of a couple of methods and/or some data to several classes is called "Introduction" in AOP language... Yep, that's right. AOP doesn't have to be about interception! That's pretty shocking considering the usual logging examples, right?

Talking about how AOP isn't only for logging, I recall the preparations for a workshop around a year ago. There were loads of design problems up for discussion. Rickard Öberg said, and proved, that all of these problems could be solved with AOP and that totally blew my mind! Even though I don't see AOP as the silver bullet, it's definitely something I'd like to have in my toolbox!

Oh, and finally, I just read here that John Lam has changed his mind and now thinks AOP is interesting again.

Course update, again

Thu, 14 Oct 2004 14:30 +0100

I'll be giving my course with LinSoft again in early November, this time in Stockholm. The course is now called "Patterns with .NET" and you find the "formal" information here (in Swedish only).

I've decided on a couple of pretty large changes:

  • I have made the course shorter so there won't be any scheduled evening hours. Because of this I have cut out a couple of less important pieces and expect to improve the quality during the scheduled hours instead. There will be optional tasks for those who have nothing to do in the evenings!
  • There will be more of a focus on Domain-Driven Design (DDD) and Refactoring. We will still of course discuss the basics of some patterns one by one, but the driving force of the course will be about applying DDD and then to add infrastructural support. In this way the patterns will be seen in their context. It will also make it pretty natural to have interesting exercises.
  • I will use some free and easily available technology as the enabling infrastructure for DDD. The one we will focus on will be NHibernate, not necessarily because it is best, but because I think it fits in well in a general course.
"Unfortunately" there aren't any available seats on the course. HOWEVER, since there has been a lot of interest, we have added an extra course in early December, also in Stockholm. As I write this, there are still places available for this one.

Upcoming presentation: Applying DDD with .NET

Wed, 13 Oct 2004 21:41 +0100

I'll be talking about how to apply DDD with .NET at Dataföreningen (the architecture group) in Stockholm in late November. The presentation is free for members. More information here (in Swedish only).

Guest post at Rocky's blog

Wed, 13 Oct 2004 21:40 +0100

Rocky Lhotka added an email from me as a guest post at his blog here. I thought it would be good to mention something other than DDD, since that's what I've mostly been blogging about lately.

SOA hangover?

Tue, 05 Oct 2004 23:35 +0100

I've got this feeling that there is a SOA (SO) hangover. Do you agree? This led to me constructing the following "law" of hype evolution:

  • First hype
    (or "wow, X is the answer to everything. It'll put an end to war and forests will be green again")

  • Then hangover
    (or "sigh, there are so many difficulties with X...")

  • Finally positioning
    (or "ah, X would provide an elegant solution to *this* nasty problem we've now got")
OK, OK, I guess there *might* be some slightly more evolved theories about this...

DDD style, take 2

Tue, 05 Oct 2004 23:30 +0100

Steve Maine continues his very interesting series about a DDD style here, here, here and here. Steve Eichert does the same here and here. As I said in my previous post, my current favorite style is a bit different to this which is why I want to describe some differences again since it will help me challenge the solution I'm using now. The life cycle of my entities is a bit different to how I understand Steve's to be. My entities start their lives in a Factory class (when needed), that is, a DDD Factory, which means that the main purpose is to encapsulate the creation knowledge. What is created is a transient entity instance, with nothing being said about persistence as yet. Then, in my case, the way to signal the instance for persistence is to call AddX(instance) on the right repository. The repository then registers the instance with the Unit of Work (UoW). The instance will now be persisted to the database at the next commit call to the right UoW. The alternative way of signaling for persistence is to hook the instance to a parent instance, such as adding a new OrderLine to an Order. I use persistence by reachability and therefore the newly created OrderLine will be persisted when the UoW which the Order belongs to is committed the next time. My Factory classes are only creating new instances which haven't been saved before. It is up to my repositories to reconstitute old instances from the database, at least when it comes to the Domain Model. Most of the real work is done by the infrastructure. I see Lazy Load as being something technical, and it is not important for the Domain Model itself. On the other hand I see Repositories as being part of the Domain Model. What I mean is that Lazy Load isn't about capturing knowledge about the domain, rather it's just a performance thing. I mean, it's for creating the illusion that the instances are around when you need them, but without the cost when you don't need them. Sure, this illusion creates some nasty problems, but let's not go there now. That's why I think it's OK to leave Lazy Load to the infrastructure, even if it bypasses the Repositories. Another way to see this is in regards to Eager Load. Assume it's time to think in sets, such as when you want to fetch a list of Orders and all the OrderLines for each Order, but you don't want to Lazy Load the OrderLines in this particular case. Instead now you want to Eager Load the OrderLines. Hopefully the infrastructure will only make at most two roundtrips to the database to fulfill that request, instead of making one call to the database for each Order to fetch the OrderLines of that Order. Let's say instead you go for an Eager Load strategy that goes via the "GetById" calls to the repositories in the Domain Model. This could be when the Orders are fetched and then we call, for instance, GetOrderLinesByOrderId() for each and every Order on an OrderRepository. In this particular case that solution would be extremely costly. Sure, I might have stretched it a bit, but you get the picture. :-) In my previous post about DDD style I talked about having a UoW spanning several repositories/aggregates. I do find having such a "global" UoW a bit troublesome. One idea is to let each repository have its own UoW. This would create a less coupled Domain Model (and then my Repositories would probably also be closer to how I think Eric describes them). All navigation bet[...]

A DDD style

Wed, 29 Sep 2004 15:30 +0100

I agree with Brendan Tompkins that Steve Maine wrote a very interesting blog post here. I'm looking forward to the next part!

The result Steve comes up with is pretty different from my own current favorite style. Not that that means mine is better, but I thought it might be interesting to say a few words in comment to Steve's article. The major differences are:

  • I don't want my Entities to talk directly to the Repositories themselves. The way I see it, only external consumer classes (in the Application layer in Eric Evans lingua franca) should talk to the Repositories.

  • I use a specific interface for each Repository. I guess I would be more inclined to try a generic interface approach when I have generics in place, but it might still be problematic. The main purpose of my interfaces is to make it easy to start with a stubbed version of each repository for TDD purposes.

  • I think of the infrastructure as something that is external to the Repositories. Sure, the Repositories communicate with the chosen infrastructure, for instance when executing queries and preparing to persist an entity, but the actual work itself is done by the infrastructure. I guess this is a bit cryptic, but it gets clearer when you consider saving. Then I let the infrastructure provide a Unit of Work (combined with an Identity Map) that is shared between several Repositories (given to the Repositories at instantiation time). When it's time to persist all changes registered to the Unit of Work, the consumer tells the Unit of Work directly to take care of it.

  • I don't use nested classes for the Repositories, probably because I first write a stubbed Repository for TDD purposes and it would feel strange to have two Repositories nested within each Entity.
Why is my current style so different? Again, I'm not sure it's better, but it's different, at least.
Perhaps this might explain it:
  • As I said, I want an external Unit of Work to control the complete object graph that the Repositories act upon. This makes it easy to store changes to both the Customer and the Address from Steve's example within the same physical database transaction.

  • I started out thinking about the style with an OR Mapper in mind for the infrastructure. Sure, I could also write the whole persistence thing for my style with custom code, but it becomes messier.
I haven't really tackled the problem Steve was trying to address here, i.e. having two Aggregates with one of them being a composition of the other one, and I would probably try to design away from the problem. However, if it's just not possible (OK, perhaps "suitable" is a better word), then I would go for infrastructure supported Lazy Load or let the load be dealt with from the external consumer. Neither feels optimal, but both work.

Again, I'm looking forward to Steve's next article on this topic! Your take?

Jimm i bette?

Tue, 28 Sep 2004 23:01 +0100

No, I haven't tried to invent a new language or anything like that. I was just thinking out loud that perhaps "Jimm is better than Jimmy" because I learned last week during JAOO that both AOP and SOA have lost their last letters so they are now AO and SO (OK, to be honest I knew about SO before JAOO). Trend conscious as I am, I am now trying to apply that new trend everywhere.

Yep, JAOO 2004 took place last week and I thought it was a great event! I did learn loads of important stuff too.

Want to have a look at Valhalla?

Tue, 28 Sep 2004 23:00 +0100

We have now published Valhalla in its current state. It's not finished, but we are interested in hearing what people think and whether anyone finds it interesting enough to help get it finished. You'll find more information at Chris's blog here.

Valhalla will be open sourced at JAOO

Thu, 16 Sep 2004 21:55 +0100

From day one of the development of the Valhalla framework, we (Christoffer Skjoldborg and I) decided that Valhalla was going to be open sourced and completely free. The original idea was to release Valhalla when it was done. We've been asked numerous times by nice people if they can have a look and/or help out, and we've just kept saying:
"When it's done."

It's still not done, but we have actually decided to open source it now. You might think:
"Yeah, just what the world needs, another O/R Mapper for .NET."

Sure, there are a lot of good O/R Mapping tools out there now for .NET, but we still think Valhalla has some special and interesting features. And to be honest, the Valhalla O/R Mapping isn't all that pronounced. Valhalla's strengths lie mainly in other things!

Hopefully we can get some interested people to jump on board and help out on fixing the last stuff for a first production quality version. If you are interested, we will be announcing where to go next week during JAOO.

A COMB-killer

Mon, 13 Sep 2004 21:40 +0100

I wrote an article in late 2001 called "The Cost of GUIDs as Primary Keys". The article was about an INSERT-problem you might run into when creating GUIDs with NEWID(), and using the GUIDs for primary keys in very large tables. The problem was that the GUIDs were random numbers in Windows 2000 and beyond. I proposed a solution that I called COMBs instead. They were still GUIDs, but created in a way that made them kind of sequential.

My Friend Tibor Karaszi told me about the new function called NEWSEQUENTIALID() in Yukon (SQL Server 2005) beta 2. It deals with the same problem, but it creates true sequential GUIDs, unlike my COMBs where just the six bytes to the right were sequential (or actually based on current date and time).

Here's an example (start reading the result values from the right):



Mats is hooked

Mon, 13 Sep 2004 21:35 +0100

Mats Helander wrote a great blog about TDD here.

I've discussed this quite a lot with Mats before, and I failed to get him interested in TDD. Charlie Poole did a better job. Mats is now a TDD freak!

O/R Mapping and .NET

Tue, 07 Sep 2004 23:55 +0100

First of all, for those who are wondering, O/R Mapping stands for Object-Relational mapping and is a technique for dealing with data access transparently in those cases where it is suitable. O/R Mapping makes it possible for you to focus more on your object-oriented model than your database schema and SQL. The end result is that you work with data in form of your own, custom objects rather than the generic framework objects such as the DataSet.

With that out of the way, let's get going with this blog-post. As you probably know, MS has delayed ObjectSpaces (Microsoft's O/R Mapper) again and the current plan is now that it in some reincarnation will see the light of day together with WinFS after the release of Longhorn.

A friend of mine has joked that Microsoft have delayed a lot of interesting things lately, such as ObjectSpaces, MBF, and WinFS. He says that generics might be next. This is a joke! I hope...

Back to O/R Mapping. Perhaps it's no longer a priority for MS since there are so many good O/R Mappers now/in the way? Let's have a look at a few examples, and please note that I'm not saying one is better than the other. I'm just trying to raise the interest for this segment as a whole. (Heck, I don't even have an opinion as to which is best myself... and as usual, the answer will vary depending on the context.)

A few examples, starting with some commercial offerings:

  • LLBLGen Pro had improvements in the GUI experience in the latest release. They also now support for Oracle 10g and Firerbird 1.x/Interbase 6.
  • EntityBroker 2004 is out now. EntityBroker has a special focus on remoting and distributed scenarios.
And here are a few open source examples:
  • NHibernate is a port from the very popular Hibernate in Java-land. (Currently in alpha.)
  • NPersist by Mats Helander, who previously wrote the Pragmatier O/R Mapper. Mats has also written a commercial GUI tool called ObjectMapper.
  • Neo has its roots at ThoughtWorks. It has some special features for rich clients and can work with non-database data sources.
Again, there are more! It's time to try O/R Mapping with .NET projects too!

Another book acronym

Tue, 07 Sep 2004 23:50 +0100

Here's another book acronym that you have to learn: R2P.

It stands for "Refactoring to Patterns". The book is written by Joshua Kerievsky. I just received my copy and have only had a quick look, but it seems to be VERY good!

JAOO update

Thu, 02 Sep 2004 08:06 +0100

I just learned that my friend Christoffer Skjoldborg will be able to pair-present (pretty XP-ish, right?) the presentation called "Persistence lessons learned when building the Valhalla framework" with me. That will be a lot of fun! And not only that, it's good because he has put in by far the most energy into the framework so far.

BTW, a few weeks ago I was passing by Århus where JAOO is being held in late September. For a Swede, the roads are pretty nice in Denmark, for instance, there's a highway all the way from Copenhagen to Århus. What I didn't know last time is that Denmark now has a speed limit of 130 km/h on highways if nothing else is stated. So I drove at around 110 km/h when signposted, and when the traffic signs said "end of 110" I was very surprised. A very nice road, and I'm not allowed to drive 110? I thought I had to slow down to the general speed (which is 80 in Denmark). It was just damn impossible to drive that slowly. It was pretty hilarious (at least my wife thought so) when I found out that it was 130 instead...

Take my word that I won't forget about this the next time I drive there.

It helps to nag!

Mon, 30 Aug 2004 23:30 +0100

My old friend Dan Byström just published a new blog post. I've been doing some serious nagging. I don't know if that's actually why he posted, but it doesn't matter. He posted.

I've been working with Dan for 15 years on numerous projects and working with him is always a pleasure. He is absolutely one of the best programmers I know (perhaps the best).

So, now it's up to you. Make sure you read his blog so he's inspired to write more. I know he has loads of things to write up that I'd like to read!


Mon, 30 Aug 2004 23:29 +0100

This is important information for all Swedish .NET developers. Sweden has a recently started .NET User Group called "SweNUG" which is an INETA .NET User group. Jonas Ekström is the Group's administrator.

Not as important, but still information - I will be giving a presentation (in Swedish) at SweNUG in November. The presentation is called "Best practices for accessing data using .NET".

Mon, 30 Aug 2004 23:28 +0100

I'm going to be giving a presentation at Windows Technology Forum in Stockholm this November. The conference is being organized by ibceuroforum and I will be speaking about Test-Driven Development. (All presentations will be in Swedish.)

Among others, the speakers will be Tibor Karaszi, Jimmy Andersson and Patrik Löwendahl.

I hope to see you there!

Granularity and SOA

Wed, 25 Aug 2004 22:28 +0100

First of all let's agree on (or at least assume) that services are great for crossing borders, such as platform borders and/or company borders.

But what about the internal structure of such a service? Should it be built of several smaller services? For a while now I've been trying to get a sense of what the heavy SOA people think about the granularity of services, without luck. When reading some texts, you might get the impression that the services should be extremely fine grained, which I have a problem agreeing with.

The keyword above was "extremely". If you decide to go the route of creating extremely fine grained services you should note that it will carry a cost which could potentially be very high. For example, you can't and shouldn't use physical database transactions spanning several services. Sure, you can use compensating solutions instead, but this adds complexity where you might not need it. (Another reason why services should not be broken down to the extreme is the added communication overhead.)

The result you get when breaking down the services is that borders are added within your services. Believe it or not, those borders not only have benefits, they also have costs.

Damn, it seems to be a matter of tradeoffs as usual. A rule of thumb like "always do it like this" might be hard to find.

Weird and sad

Wed, 18 Aug 2004 13:12 +0100

The other day I talked to the guy who used to be responsible for the Software Engineering (SE) program at BTH in Ronneby, Sweden. He said that almost nobody's applying for the program any longer, which really shocked me. Only a few years ago it was hugely popular, and now that the IT economy is coming back so strongly, I was so sure the program was popular that I hadn't given it a second thought.

I think it's something of a paradox since I believe that the industry is screaming out for engineering in software development (not as the silver bullet and the only thing necessary, but as one particular thing there is a lack of.) Here are a few blog posts from off the top of my head:

Local representatives from Symbian were on the local TV news the other day, expressing great concerns that there are so few interested in studying software development of any kind, and software engineering in particular. Perhaps this is what is needed - companies explaining loudly and clearly what training and qualificiations they consider to be important for the future.

Talking about BTH, nowadays they are heavily into SE research, but that doesn't seem to help this problem at all.

I think the job situation for software engineers is pretty good right now and if I'm right then it won't be very long until they are very hot!

I was hoping BTH could be persuaded to give a modified version of the SE program as a program for software architects, but I guess that won't happen now. (Just to make it clear, I don't think it is possible to become a software architect through study alone, but I think it's possible to create a program that gives a very good foundation.)

I just don't get it. Why aren't loads of students applying for a program like that? Is it a global trend or a local thing?

Yet another must read

Tue, 17 Aug 2004 22:50 +0100

Vacation time is probably over for many of us now so I bet you need some new book tips, right? I have just started reading Rod Johnson's new book which is called "J2EE Development without EJB" and it is VERY good!

BTW, Rod will give presentations at JAOO. Yet another good reason to go there!

Separate UI from logic

Tue, 17 Aug 2004 22:45 +0100

One of the most basic principles in design is to separate the UI from the logic. I'm not going to discuss a whole lot of reasons for that. Let's just summarize it as a matter of separation of concerns.

What I'd like to write in this blog post is that there are "new" reasons every now and then for why this principle is a good idea to follow. Some examples:

  • I listened to the .NET Rocks show the other day when Miguel de Icaza, one of the main guys behind Mono, was the guest. (Mono is an open source implementation of the .NET Framework, which runs on Linux and MacOS. And Windows.) He said on the show that if the funds for your project were there, he recommended writing three versions of the presentation for applications. One in Cocoa# for Mac, one in Gtk# for Linux and one in WinForms for Windows. Then each presentation version would gain as much as possible from each of the execution platforms (as opposed to other common approaches for multi-platform client UIs). The model (or engine as he called it) could be implemented once. (Nope, I'm not going to go on again about how I like the Domain Model pattern [PoEAA] for many situations and that I think that's what Miguel was thinking about...)

  • Perhaps the Tablet PC is taking off really soon. If you want your app to be really nice on that device, you should obviously build the UI specifically for the tablet.

  • The Compact Framework might also really take off, perhaps not with Pocket PCs as much as with cell phones. Anyway, this might mean that you might want to factor out the UI as much as possible from the model.

  • As I understand it, XAML (the upcoming way of building UIs in Longhorn) is very much about separating the presentation from the logic.

What do you think about Prevayler?

Sat, 7 Aug 2004 11:50 +0100

Let's make a couple of assumptions and then get back to the question in the heading.

  • One of the tenets of SOA says that services should be autonomous. That leads to the assumption that each service should have its own database. The database might live at the same server as the one running service. Harry Pierson at Microsoft wrote a piece about that here.

    (Cynics say that Microsoft like to think this way because they want to sell more SQL Server licenses which means Microsoft would make a lot of money out of that. :-) I don't think that's what Harry was thinking about at all, rather it was more on a conceptual level. Let's assume further that a new licensing model for SQL Server would prove cynics wrong on this one anyway.)

    BTW, to further emphasize this assumption, see the blog posts here by Martin Fowler.

  • Assume that I was right to some extent when I said here and here, for example, that it might often be interesting to use the Domain Model pattern [Fowler PoEAA] within a service.
So, now we have the assumptions in place. Do you think it would be interesting to investigate Prevayler (or one of the ports) in the future for some of the services you are about to develop?

Clarification: I'm not against relational databases or OR Mappers. On the contrary (for example, see this post as "proof" of that)! I'm just curious to hear what you think about the "Domain Model as the database" approach for databases that aren't huge. You can reach me here.

Presentation logic

Sun, 25 Jul 2004 23:15 +0100

For quite a while some friends and I have been discussing whether it would be a good idea to create a framework for helping out with connecting the UI to a Domain Model [PoEAA]. Sure, there is data binding support in .NET and it works pretty well, but you need to add lots of uninteresting infrastructure code to your Domain Model. And the data binding works best for simple scenarios. Other things to consider are whether you want to hook your forms directly on to the Domain Model or if you need kind of a view of the Domain Model instead, whether there is more that can be done to help productivity, and so on, and so forth.

While discussing this, I was surprised that there is so little being written about it. Why is that? The answer is not that everything is solved if you're using DataSets to represent the Domain Model, not at all.

It's not completely quiet, however. Here are some disparate examples of certain interesting points:

  • First of all, something quite different from what most of us are used to is the idea of "Naked Objects", which means that the Domain Model objects themselves will automatically get a UI representation without any extra code having to be written.

    I felt I had to explain Naked Objects a little bit inline above so as to not receive scorching emails for using that term. I'm sure this blog post will get a great number of hits...

  • Rockford Lhotka has written an article about the Data Connector in Visual Studio .NET 2005.

  • Paul Wilson is talking about creating a UI-mapper here, here and here.

  • Microsoft has dedicated an application block called "User Interface Process Application Block" to this area.

  • Martin Fowler has recently published early drafts for patterns about organizing presentation logic here.
Perhaps the interest in this area is taking off now. What's your take?

Response to Clemens, part 2

Sat, 17 Jul 2004 22:50 +0100

I know, it was a trap. Clemens was just being a bit extreme in order to get some discussion going here. Anyway, I feel obliged not to let Clemens feel disappointed so I'll continue what I started in this post. I'm VERY interested in SOA and want to learn more. In order to keep the discussion going, I'll play devil's advocate... :-) Oh, before I forget, Philip Nelson wrote a great comment here that almost made me not write a second post about this subject, but here it is anyway. Assume that the domain model is a local one for the consumer, and the consumer orchestrates lots of the functionality by calling different services. In this case I think encapsulation and inheritance in that local domain model could well be just great. I've heard several times that the services according to SOA get very small and fine grained. That's because services are like fractals, they are built up of smaller services, recursively. But do you really want the services to be extremely fine grained? For example, wouldn't it be a bad thing when it comes to, say, compensating transactions? At least that's my gut feeling right now. Another example is the first service tenet (discussed here) about service boundaries that are always potentially expensive to pass. If you take it that far, then extremely fine grained services might cost too much regarding performance. A wild guess is that we will come to the conclusion that not too fine grained and not too coarse grained is the best. :-) In response to Clemens' post, some people recommended long switch statements on types as a good solution. I think it's considered a smelly solution in the OO community. How can it be avoided? Often with polymorphism (which in all fairness doesn't have to use code inheritance). What is OO good for? I think it's good for dealing with complexity. If you don't have a complex scenario (typically regarding behavior), then you don't benefit very much from OO. To prove that I'm not a turncoat I want to point out a past post of mine here. Oh, and if you are interested in this discussion make sure you don't miss the posts from Udi Dahan and Steven Eichert either. Their posts aren't in the comments to Clemens' posts. You find them here and here. Finally, I like this post at Richard Turner's weblog a lot. It's not SOA or Domain Model. They complement one another! (If you read the comments, you might get the feeling that Richard is pretty anti-Domain Model after all, but I forgive him.) From now on I consider that post by Richard to state the official MS standpoint. Or was it just another trap? ;-) [...]

Till mormor

Fri, 9 Jul 2004 10:00 +0100

To the geeks who normally read my blog, I,m making a rare exception today and writing a non-technical blog post. It's for my grandmother, a real super grandmother! She didn't get the chance to learn English in school so I'll just switch over to Swedish here.

Vad ger man sin mormor när hon fyller 80 år? Inte enkelt. Det var decennier sedan hon skaffade allt hon behöver, men nu fyller hon år på måndag så jag måste ju komma på något riktigt, RIKTIGT bra.

Det känns viktigt. Hon har alltid varit en mycket viktig person för mig. Min morfar gick bort i unga år, men mormor har axlat båda rollerna i alla år därefter. Det har säkert varit väldigt tufft, men mormor alltid fixat det på bästa vis. Och ni skulle t ex se hennes trädgård. Stor, men ändå alltid finare än en park!

Mina första år så var jag hos mormor istället för på dagis när min föräldrar jobbade. Därefter var jag hos henne efter skolan nästan fram till tonåren. En så trygg och bra uppväxt som man bara kan tänka sig.

I vuxna år har det alltid varit favoritstället att åka till för att fika. Det är inte många ställen man får kokkaffe på gammalt vis. Och alltid har hon hembakat. Mycket gott. För att inte tala om hennes kroppkakor som hon gör i enorm mängd (tre dagars arbete!) och sedan bjuder in alla barnen, barnbarnen och barnbarnsbarnen. Att göra kroppkakor är tufft för en tjugofemåring. För en gammalmormor, jo, jag förstår inte hur hon fixar det. Men det gör hon. Om och om igen. Och kroppkakorna är oslagbara, tro mig!

Ja, vad ger man till henne? Ah, en extra påhälsning förstås. Det sker ju alltför sällan nu förtiden. Det får det bli, och en vanlig present. Och så en alldeles egen blog post. Det är jag ganska säker på att hennes väninnor inte har fått. Hon är inte direkt så mycket för datorer och sånt, men det kanske är kul att vara en cybermormor för en dag. Grattis mormor! Många kramar!

Från Jimmy med familj

Response to Clemens

Thu, 8 Jul 2004 22:30 +0100

It's almost time for my vacation, but I couldn't resist writing a blog post in answer to the post by Clemens Vasters called "Rows and Columns + Elements and Attributes is all you need". Not that I think I can teach Clemens anything of course, but I'd like to try some off-the-cuff arguments. And if the arguments don't work out, I can work on them during the vacation. Hey, Clemens probably set a trap with that blog post, but traps that nobody walks into are no fun, right? :-) So, here are some comments in no particular order: Perhaps the whole discussion is about what is the best paradigm for business applications, OO/Domain Models [Fowler PoEAA] or some other paradigm? The choice of paradigm depends on many things, including what feels most natural for the developer. I can't say I use implementation inheritance very much in my Domain Models, but there are times, for instance, when I find that Strategy [Gamma GoF] will make the Domain Model clearer. Implementation inheritance is just another tool that is in no way useful all the time, but can be sometimes. (The tool called interface is probably more useful much more often.) I think implementation inheritance might be what I decide on during Refactoring to avoid code duplication, for example. It's not extremely common, but it happens. When communicating with coarse granular SOA-like services, I agree with Clemens. There we should use documents with "global" and totally visible data. However, within a service, I still believe it's a good idea not to let data be global, but rather as much encapsulated (or rather information hidden) as suitable. Global data just won't be as efficient when it comes to robustness and maintainability as encapsulated data and the risks of side effects are typically greater. When the merits of SOA are discussed, and how much better it is than Domain Models I think a very common misconception is that SOA and Domain Models not in the least bit apples and apples. For example, for a complex service, there can of course be a local Domain Model. Just because you use Domain Model, it doesn't have to be one huge monolithic one, it can still be used in an SOA-world...) I think an example that is more complex than the one about Address, typically a behavior heavy Domain Model or one with advanced relationships, might make it easier to justify encapsulation and implementation inheritance, especially if we are trying hard to avoid duplication. It may be naïve, but I still believe that traceability from analysis, or at least early model-driven design (which is pretty similar to OOA), down to code (both ways) is a good thing, at least as something to have as a goal. I agree with Clemens that code reuse of classes such as Customer is hard to achieve between dissimilar projects. I'm pretty happy if I can get by with just one Customer cl[...]

JAOO 2004

Sat, 26 Jun 2004 11:30 +0100

Summer is coming to Sweden any day now I hope. Heck, we celebrated midsommar (midsummer) yesterday and it rained and it was cold.

Even though we Swedish guys love and long for our short but most often wonderful summers, there is actually one thing that's already making me long for the autumn. Namely the JAOO conference in Århus in Denmark in September.

The speakers are Martin Fowler, Anders Hejlsberg, Frank Buschmann, and many others. I will be giving two presentations and hope to see you there!

Books for the beach

Sat, 26 Jun 2004 11:26 +0100

It's been a really tough winter and spring workload-wise, but I hope things will cool down a bit now for the summer - apart from the weather of course. Have I told you before that we Swedes are extremely weather fixated?

So, if you manage to find time for a couple of days on the beach, it's important to load up with books to read, so I'd like give a few read tips. First out is "Enterprise Patterns and MDA; Building Better Software with Archetype Patterns and UML", by Jim Arlow and Ila Neustadt. I have just started reading it, but I'm particularly interested in the Archetype Patterns they discuss. They are like domain sub-models that you can reuse in your own domain models, or at least use for inspiration.

Another book that I should have read a long time ago is "Design & Use of Software Architecture; Adopting and evolving a product-line approach" by Jan Bosch. In the past, I worked in the same department as Jan at a University in Sweden. It's actually very embarrassing to admit that I haven't read the whole book yet... but there's lots of time for that now!

Finally, the third tip is about a book that isn't out yet. It's called "Software Factories: Assembling Applications with Patterns, Frameworks, Models and Tools" by Jack Greenfield and Keith Short. I've read a couple of chapters from the manuscript and it's very interesting. A must read! It will be released in July.

A decade with singletons

Wed, 19 May 2004 09:50 +0100

The other day I wrote a blog post about my life with factories here. Now it's time to tell you a little bit about my life with singletons.

I first read about Singletons in a paper from the GoF guys when I worked part time at the university. I remember it was one of the first patterns I tried to implement with VB4 when I got my hands on it. However, after a few hours I decided that I wasn't able to implement it close enough to the intent of the original pattern...

When I run my course "Design Patterns and Architecture Patterns with .NET", I always start by asking the attendees what they think the most interesting thing about the course will be. Once one of the attendees said that he thought the name "Singleton" sounded so cool that that was the reason he came.

A year ago, I was driving outside Denver and I saw on the map a small village called Singleton. For some reason that village didn't exist - the name had been changed.

Finally, I'd like to mention that an old (and *very* good) student of mine, Petter Nordholm, is one of the founders of a consultant company called Singleton. The name *is* pretty cool after all. What design pattern name would you like for your company?

Book title quiz

Fri, 14 May 2004 14:22 +0100

Seven of my absolute favorite books are (in alphabetical order):

  • DDD
  • GoF
  • JDO
  • PoEAA
  • POSA
  • PPP
  • TDD
Do you know all of them? The first one to know the books wins a secret prize.

*If* I'm going to write a new book, I have to think long and hard about a good acronym!

Update: And the winner is Eric Kinateder, congrats! Russ Condick was just one(!) minute later.

AOP and .NET

Sun, 9 May 2004 22:00 +0100

As you might remember, I have written about AOP a couple of times here before. (Here and here.) Things are happening with AOP and .NET too. I spoke to my friend Rod Johnson the other day and learned a bit about his project called Spring.NET. It sounds VERY interesting to me.

There are also other projects in the works such as:

Do you think AOP is the next big thing or is it not very useful at all? My guess is somewhere in the middle. As always.


Sat, 8 May 2004 14:30 +0100

Absolutely the most interesting discussion list right now is, in my opinion, Domain-Driven Design. It's described like this:

"This group is for discussion of the domain-driven style of designing software, and the book by Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Business Software."

Updated beta version of part 7

Thu, 6 May 2004 21:50 +0100

Do you remember the beta version of part 7 I mentioned here? Now I have updated the beta version of the article so that it's complete. I have also changed it so that it reflects the current state of the Valhalla framework. You'll find the new (and final?) beta version here.

All comments are welcome!

Early spring in the south of Sweden

Mon, 3 May 2004 13:30 +0100

Last week I gave a course close to where I live, at Krutviken in Karlskrona. I told you before that their food and surroundings are just great. I didn't take a photo of the food, but here is one taken from the window of the course room with a pocket camera. (image)
Pretty nice, eh?

And to my international readers faraway, this is Sweden in early spring. No snow or ice!
In fact, down here in the south of Sweden there is actually very little snow or ice in the winter either, more's the pity.

TDD Transcript

Thu, 22 Apr 2004 12:15 +0100

I thought it would be a good idea to write a transcript of my TDD presentation I gave the other day. After all, I did get a BSOD (Blue Screen Of Death) in the middle of the demo. Well, actually it wasn't blue, it was black as in the original definition. Everybody knows about the power supply problems in San Francisco, right?
I did use a laptop with batteries, and nobody else had a problem like this so perhaps it might not have been the power supply after all...
Demo ghost, that's it.

Anyway, the BSOD took a few minutes from my presentation so I didn't have time to discuss the last concept slides, but if you want to have a look at what I was planning to say, or if you couldn't make it to the presentation, here's the transcript.

I might transform this later on into an article or something similar.

Techies and Windsurfing

Wed, 14 Apr 2004 21:10 +0100

A techie friend of mine has just started a windsurfing company. It's in the south of Sweden, but probably still way up in the north for most of you. Therefore I thought I had come up with the perfect name for the company: "Northwind". Unfortunately I was too late; he had already given it another name, "Brett".
Check out the site here (in Swedish only).

I have to try that sport again. The first and last time I tried it was something like thirteen years ago, and I ended up in the emergency hospital. I broke the mast over my foot. Every nurse on duty that evening came in to look at my foot and had a good laugh. It wasn't the commonest cause of a bad foot, they said.

Tools and teeth

Wed, 14 Apr 2004 21:05 +0100

The other day I bought a new toothbrush, the Rolls Royce of toothbrushes as the sales girl told me. As a matter of fact, she told me everything about it without me even asking. She was totally amazed by it and after having used it for a while now, I understand her. It's just great!

"Jimmy must mean something by this weird opening" you say. Well, let's see.

I have quite often said, at different times, that it's not about tools, it's about the mindset and about knowledge. A past example is that I've said that you can and should use programmer testing even if you didn't have a lot of tools. Another good old example is that I've seen horrible database schemas created by owners of ER-tools.

Anyway, if you have the right mindset and the knowledge, then having good tools won't do any harm. On the contrary, good tools will do a lot of good! For instance, now I think it's a lot more fun brushing my teeth!

How to get started with TDD

Wed, 14 Apr 2004 21:00 +0100

After my presentation about Test-Driven Development (TDD) at VSLive the other day, a couple of guys told me that they love the idea of TDD, but they have a hard time getting started each time they try. One of them said that he had a couple of setters and getters, some add methods, and some calculations, but it's very hard to know where to add tests.

I think the problem here is that there has been a bit too much detailed up-front design and that actually makes it harder to get going with TDD. Forget about the properties for a while and focus on one of the calculations, write a test for a simple step in the calculation, write the code, refactor, write another test, and so on. That will probably show the properties that are really needed. That should get you started.

Sure, it is a bit hard to get going with the TDD thinking. You need to force yourself for a couple of days. After that, you probably won't want to go back.

ObjectSpaces rumours

Fri, 02 Apr 2004 15:13:00 +0100

There have been a lot of rumours the last few weeks about ObjectSpaces. Here are some new and official words from Microsoft:

"ObjectSpaces is not participating in Whidbey beta 1, however, it remains part of the Whidbey/Yukon wave and will be made available as a downloadable add-on pack for the .NET Framework Whidbey shortly after Whidbey ships. This additional development and stabilization period will be focused on improving the overall ObjectSpaces programming experience and providing tighter integration with WinFS, the next generation file system in Longhorn. The schedule for the ObjectSpaces mapping tool is also being adjusted accordingly."


Thu, 01 Apr 2004 22:42:00 +0100

A few months ago, I wrote a little bit about how I wanted to see good support for AOP in .NET here. Not as the silver bullet, but as an additional tool in the toolbox.

The other day, some friends of mine (Frans, Philip, Rickard) mentioned that IBM have decided to do something in this area. For more information, see here.

Write and maintain code faster

Thu, 01 Apr 2004 22:41:00 +0100

I listened to a lot of Microsoft presentations about Visual Studio .NET 2005 the other day. What all the presentations had in common was that (ObjectSpaces wasn't mentioned once, but I'll get back to that another time, and) they said something like "and all this was done with zero lines of code", after just having built a huge web site, the control system for a space craft or something like that. After a while I started wondering "why"? I like code. Why shouldn't we use code? For the right things, I mean. Well, I guess it's a demoware thing...

Later I met Mark Miller. He is the Chief Architect of the Tools Division of Developer Express. He showed me their CodeRush product and I liked it a lot. In fact I liked it so much that I'm now using it all the time when writing code. It helps me write code in Visual Studio .NET much faster and actually write better code at the same time.

Course update

Thu, 01 Apr 2004 22:40:00 +0100

As you know, I'm always going on about my course called "Design Patterns and Architecture Patterns with .NET" and here I go again. I have made a couple of changes to the course, and here they are in brief: From the first time I gave the course, the labs and all examples have been driven with NUnit, but now I'm putting a lot more emphasis on TDD in the beginning of the course. Not as something that is particularly important for the course per se, but as something to take home as yet another tool for the toolbox. A friend of mine recently said that patterns are great, but they are hard to grasp theoretically. What he preferred was to see some code in action and afterwards learn the pattern name for it. I have previously started from a realworld problem and then discussed a pattern as a possible solution to the problem. I'm going to mix that a bit, starting from code. Trying out patterns by writing code is a great way (the best?) of getting a feeling for how they work, but it is very time consuming to do this during the course. Therefore I will also introduce some theoretical design labs, and also refactoring pieces of code by applying patterns. The great book "Domain-Driven Design" by Eric Evans has influenced the course quite a bit. And I will as usual discuss the latest findings in the development of the framework Valhalla... While I'm at it, I'd like to say something important about necessary experience and knowledge in order to be able to learn about patterns. You don't need a lot of knowledge about Java, C# or VB.NET, nor do you need a lot of knowledge about OO. What I think is needed is just a little experience with a .NET language, for example, and a little knowledge about OO with no need for other in-depth courses first. As a matter of fact, learning about patterns is an efficient way of learning OO! What probably helps the most is if you have worked on an application with maintainability problems. :-) I think it's a common misconception that patterns and such are extremely advanced. That's not the case. However, if you are anything like me you might want to gain long-lasting skills For example, I learned SQL back in 1988 and I could still make a good living out of "just" working with SQL. I first started studying Design Patterns in around 1995 and they are "still" highly useful skills to have (and probably will be for many years to come). Isn't that kind of knowledge a wonderful[...]

Something different about TDD

Wed, 31 Mar 2004 12:20:00 +0100

There is masses being written about TDD. Here is something different and very interesting by Chris Sells and Ward Cunningham.

A decade of factories

Wed, 31 Mar 2004 12:16:00 +0100

I was reminded the other day that I have changed my mind about factories many times over the last few years.

First I started using factories a lot since VB4 didn't have parameterized constructors.

Shortly after I found out how sensitive the creational code was when writing MTS components. I more or less avoided the problem of, say, creating multiple transactions instead of one by accident. Factories were a good thing as there would be no New() and CreateObject() calls by mistake, only CreateInstance().

When COM+ came with Windows 2000, most of that problem went away - at least CreateObject() was fine, but there were still issues with New() in some situations... Anyway, I had COM+ projects where I decided not to force the usage of factories.

One thing I have liked with factories for a long time has been that they can configure the instance the way it should be and the consumer doesn't have to know about it at all. The factories (especially if they are interface-based) can even decide on which class to instantiate for the consumer. Then I found out that when using Test-Driven Development (TDD) it's a good idea to let the consumer be in control of configuration. That was a reason for using fewer (or at least pretty different) factories.

When I started working on the framework that is now known as Valhalla, I decided that the simplest and least intrusive way of instantiating entities was to just use New() and until factories were really necessary, I didn't use them.

Then it occurred to me that I'm kind of violating the Single Responsibility Principle (SRP) when I have my creational code in the class itself. Eric Evans' book Domain-Driven Design was a good reminder of that. He uses a very good metaphor of a car engine. The car engine doesn't know itself how it is created, that's not its responsibility. This argument is especially valid in cases where the creational code is complex.

OK, what's the moral of the story? I have no idea.
Well, it might be that you can't just decide to always use factories or always skip using them. As for everything else, it depends. It's good to be reminded about that every now and then.

White Box vs. Black Box

Wed, 31 Mar 2004 12:10:00 +0100

A common question regarding TDD is whether you should use white-box or black-box testing. Should you test private methods or just methods that are publicly available (such as methods in the interface)?

I prefer to use black-box testing and test only the public interface with my automatic unit tests. The negative effect of this is that the public interface often gets a bit larger. I usually need to expose sub results as property gets. The bigger interface is read-only, so it's not a major problem. Sure, there's a risk of showing too much of the algorithm, but the larger interface often proves useful for the real consumer.

I also use ordinary assertions (such as System.Diagnostics.Trace.Assert) for pre- and post-conditions in my methods (similar to Design by Contract by Bertrand Meyer). Of course, those assertions will help when running the automatic unit tests too.

(Excerpted from my speaker tips, VSLive 2004)

Why is TDD so boring?

Mon, 22 Mar 2004 22:40:00 +0100

I'm absolutely not a marketing guy, but I used a small ploy with the title, and it worked; you are reading, aren't you?

Test Driven Development (TDD) is actually fun and not boring. That's my sincere opinion. Perhaps the reason is one of the following:

  • It might be that "what is new is fun". Using TDD is a different way of programming compared to what most of us are used to from before. To start by writing tests. And only writing real code in order to make a failed test execute successfully.
  • Perhaps the reason is that we get good productivity in the projects from start to finish. Instead of finding the bug rate increasing late in the project, the quality can be high even through pretty dramatic and late change requests are being dealt with.
  • Another probable reason is that we like the instant feedback. Did that change break anything? Compare it to how it was a few years ago when the compilation was done only at night time and you learned about compilation errors the morning after...
  • It's fun to deliver high quality. It appeals strongly to our sense of professionalism.
Perhaps the reason is more a combination (as always) of the above.

When I started with TDD, I did it mostly because I thought it was something I should do in order to increase quality in my projects. I didn't expect it to be fun. That came as a pleasant surprise.

Part 7 in beta mode

Fri, 12 Mar 2004 13:40:00 +0100

I never seem to find the time to finish part 7 of my series of articles called "A pure object-oriented domain model by a db-guy". Well, until I do you can have a look at the beta version of the article, found here.

Please note that the beta is "text complete", but it currently lacks some code examples and figures.

All comments are welcome!

Test Driven Design: some myths as to why it shouldn't be used

Fri, 12 Mar 2004 13:10:00 +0100

Actually the myths aren't just to do with Test Driven Development (TDD), but are also about writing automatic unit tests after you write the real code. (If you use TDD, you write tests before real code and let the tests drive your design.)

Myth #1: "The customer doesn't want us to add automatic tests. We have asked him."
I think it's quite likely that what they did ask was if it was alright to let the timetable slip a bit so that they could add automatic tests. It might even be so bad that the customer tells them to write correct code instead.
As I see it, this isn't something the customer should be asked about as it is all part of our professionalism. In my experience, not using TDD (or at least automatic tests) most often causes the timetable to slip much more than when I have used it. From beginning to end, I think using TDD makes me more productive, not less.

Myth #2: "We don't have any good tools for automatic testing."
Whether to test or not to test isn't about tools, it's about a mindset! Besides, nowadays there are loads of good tools, the most common one probably being NUnit. And if you still don't find the tool you need, write your own.

Myth #3: "There's no point me testing my own code."
Sure, it's likely that others will find errors that you wouldn't find by yourself (this is one of the points of reviewing.) Still, I think it's our responsibility to take away as many bugs as possible, and this way the QA department (if you're lucky enough to have one) can focus on trickier stuff. And if you use automatic tests, it costs very little for you to run the tests after each and every change.

Everyone should learn about design

Fri, 12 Mar 2004 13:10:00 +0100

If you plan on raising your development team's design competence by, say, letting some of them take a course in design patterns, then I think it's wise to allow (force ) all of them to take part.

Let's have a look at three arguments in favor of this.

Eric Evans writes in his book "Domain Driven Design" (a must read, BTW) that "software development is all design" in response to an old (and bad) metaphor that highly skilled should design, less skilled should assemble.

I recently took part in two workshops with other developers, most of whom I hadn't met before. We all came from different backgrounds, countries, platforms, etc, but, everyone was experienced with GoF's Design Patterns and Fowler's PoEAA. Actually, I didn't think about it during the workshops, but afterwards it struck me how powerful it is when everybody shares a design language. Of course we didn't see eye to eye on every detail, but we did understand each other extremely well on the whole.

Finally, I often hear from developers that "all this patterns stuff is great, but when I come back home, no-one else on the team understands what I'm talking about".

My first (and last?) blog post in Swedish

Thu, 19 Feb 2004 09:10:00 +0100

Den är inte bara på svenska, utan den den handlar om Blekinge. Jag blev nämligen intervjuad idag av ena lokaltidningen för att jag (åtminstone enligt journalisten) är den enda i näringslivet i Ronneby som har en weblog.

Det slog mig efteråt att OM min blog omnämns i artikeln som han skrev så kanske mina vanliga åtta läsare för en dag kommer vara kanske fyra ytterligare. Tänk då OM en av dessa fyra nya lokala läsare är sugen på att gå en kurs om "Design Patterns och Architecture Patterns med .NET". Då vore det ju väldigt förargligt om den personen inte fick veta att jag ger den kursen i Karlskrona i slutet av april, eller hur?

Förresten, om det nu blir fyra nya läsare imorgon fredag så måste jag passa på att köra ett litet experiment. Låt oss se om bloggning fungerar som lokal marknadsföring. Nedan följer fyra lokala småföretag som jag varmt rekommenderar! Gynna dem (inte för att vara snäll utan för att de helt enkelt är mycket bra) och glöm inte att nämna att du läste om dem här så får du säkert ett kampanjpris.

A as in Agent?

Thu, 5 Feb 2004 11:30:00 +0100

I'm not sure if you remember, but back in 1993 or something like that, AOP meant Agent Oriented Programming, and seemed to be interesting and important technology. In the last few years I think it's more common that the acronym means Aspect Oriented Programming instead. I've heard about AOP (meaning Aspect from now on in this blog post) from time to time during the last year or so, but every time I got interested, something happened that made me forget about it. One thing was this blog post written by Craig Andera where he (and Tim Ewald) states that the declarative services of COM+ just don't work, and the same goes for AOP too. Another example of a showstopper is that AOP was often talked about in the .NET community as what could be done with interception. Interception is, er, problematic right now in .NET. As I understand it, Microsoft recommends that we don't rely on interception based on ContextBoundObject or the channel sinks in remoting due to future changes. The other day I met Rickard Öberg at a workshop and he renewed my interest in AOP. For one thing, Rickard taught me that interception (or advice, as it is called in AOP language) is just one of several different mechanisms. (The others are object fragments and introductions. Here is a nice introductory article.). Rickard isn't just using AOP for the ordinary tracing and logging examples, but also as a solution for adding behavior to the Domain Model, for example. The more I thought about it, the more I wanted AOP, not as solution for all possible problems, but as an additional tool in the design toolkit. I'd like to have more of what Rickard talked about in .NET, for example so that I could add behavior to classes from a smorgasbord (fewer dots in this spelling of the word compared to the Swedish ). I'd like to be able to add one more method to a group of my classes just like that, and two more methods to some other classes, and so on, and so forth. (BTW, this mechanism is called introduction, or mixin, in AOP.) It's like extreme composition , but without paying the cost of duplicating interfaces and implementation/delegating code on the class that is wrapping the other class. One importan[...]

VS Live presentation in SF

Thu, 15 Jan 2004 15:30:00 +0100

I will be giving a presentation called "Putting Test-First Design into Practice" at VS Live in San Francisco in March. I hope to see you there!

New locations for my course

Thu, 15 Jan 2004 15:30:00 +0100

Normally I hold my LinSoft-course called "Design Patterns and Architecture Patterns with .NET" in Linköping. This spring, I will be holding it in Stockholm, Karlskrona and Malmö. I think that this will be popular with companies situated close to these locations because the total course costs for attendees will be reduced quite a lot.

You will find more information (in Swedish) here.

XDE looks very nice!

Thu, 15 Jan 2004 15:30:00 +0100

As I mentioned in this post, I gave a presentation at NRUF 2003. As preparation for the presentation, I thought I would redraw my diagrams with XDE so as not to look too strange in that context and not to be rude.

In the past I owned and used Rational Rose for years, but I wasn't too impressed and after a few years I decided to drop that tool. Because of that my expectations weren't very high, but I was very impressed when playing with XDE. It was VERY nice, so nice that I am considering buying a license again, but I need to figure out the best way of integrating it with the code generation from metadata that I use for some parts of my framework.

More and more interest for O/R Mappers

Wed, 7 Jan 2004 22:25:00 +0100

Thanks to ObjectSpaces there is more and more interest in O/R Mappers in the Microsoft community. I know that several of the vendors of O/R Mappers for .NET are worried (of course) since Microsoft will ship ObjectSpaces as part of the .NET Framework. But perhaps ObjectSpaces might be a good thing for those vendors because it will help attract a lot of developer interest to this area. I also think that several people (count me in) wanted to see something like JDO (Java Data Objects) for .NET, namely a spec that several companies could implement. Microsoft's tradition is different, as you know, as they go for an implementation instead. Yet perhaps there will be syntax compatible ObjectSpaces clones, using the Microsoft implementation as a spec. Could there be clones that, for example, support databases other than SQL Server if ObjectSpaces won't? (Disclaimer: I don't know for sure if this is allowed, but companies building products will of course know the ins and outs.) BTW, absolutely one of the best books of last year was, in my opinion, Java Data Objects by David Jordan and Craig Russell. It's very interesting as a design book, even if you don't plan to use JDO by itself. The book is full of interesting solutions to design problems and it comes highly recommended! Ingo Rammer wrote about weaknesses in the concept of O/R Mappers here. Not that Ingo is wrong, of course and you should use the right tool for the job. However, I felt I needed to comment on the second part where he talks about the transactional update. My comment was going to be something along the lines of how I solve that particular update problem by using optimistic locking (if possible, but it's almost never a good idea in this particular context of an inventory table) or by jumping out outside of the O/R Mapper, to custom SQL code or a sproc. (If you design for it, jumping "out" can be done pretty transparently of course.) But this problem got me thinking about one area of how the O/R Mapper concept could be extended. See more about that in this post. It's weird, but for the [...]

"Process Object pattern"?

Wed, 7 Jan 2004 22:20:00 +0100

Most O/R Mappers have some sort of support for queries, for example they support a query language such as OPath, PPath, JDOQL, SODA or OCL or they implement the Query Object pattern [Fowler: PoEAA]. Compared to SQL, this is set-support of the DML operation SELECT.

However, as far as I know (and please let me know about examples), it's not common for O/R Mappers to have strong set-support for the other DML operations in SQL, namely INSERT, UPDATE and DELETE. I think having set-support for INSERT, UPDATE and DELETE would be a nice addition to the feature set of O/R Mappers, so my prediction for 2004 is that most O/R Mappers will have some support for that soon.

I guess many of you think that this is a good way of complicating a "simple" and powerful thing such as SQL, right?
However, if you like the idea of O/R Mappers, you might also want to be able to work as much as possible with one programming model and one type system (perhaps type safely) without having to mix with SQL and your database schema (except for when it is REALLY needed). As usual, it's nice to be able to choose between different approaches, right?

I will write another blog post about this shortly, but first I need to publish a status article about the framework I've been developing for a while. The explanation of the ideas about the "Process Object pattern" (or whatever it should be called) needs to be put in context. Stay tuned!


Mon, 5 Jan 2004 22:25:00 +0100

Whether to use MDA (Model Driven Architecture) or TDD (Test-Driven Development or Test-First Design or whatever you call it) seems like an important choice between two opposites. Should you do a lot of upfront design? Or should you write a small test, write the code for the test to pass, refactor and so on?

Well, I don't think it's a matter of one or the other. It's both! If you start with TDD, it's great to look at and work with the code with an MDA tool from time to time. You will easily see stuff you don't see in the code.

And if you start with MDA, you should still use tests for as much of the code as possible/is practical. It's also the case for an MDA-heavy project that for the next feature to be added, you might want to start doing it with TDD.

OK, OK. I'm allergic to silver bullets. Similar ramblings to the above could be used over and over again.

NRUF, some comments

Mon, 5 Jan 2004 22:25:00 +0100

I gave a presentation at NRUF 2003 (Nordic Rational User Forum) in December. I spoke about applying architecture patterns.

The conference had a panel debate at the end of day one. Among other things, the panel said it was incredibly hard to find software engineers and architects in particular. The guy who said that proposed the development of a new university program in that area. Sounds sensible to me.

Another thing regarding universities was that someone else on the panel said something like "Universities are too quick to pick up new technology and market it hard and successfully, for example HTML-programming, instead of focusing on important things like software engineering." He went on by saying "For example, the students should work in large projects during their studies."

Another person said "All real projects put so much energy into testing nowadays, but not one university in Sweden has a course on verification."

After a while a man in the audience commented by saying something like "When I was studying at university a few years ago I worked on a large project on a course and I had a course on verification. I studied the software engineering program in Ronneby." Ivar Jacobson on the panel then said something like "Yes, universities without an extremely strong background in computer science will be more likely to understand the importance of software engineering."

Why am I telling you all this, you might be wondering? Well, I thought it was good to hear as I used to work part time there. Not that it was thanks to me that Ronneby (or rather BTH, as the university is called) gave those courses, but it's always nice to hear positive things about your old work place.