The issue that I had with creating views for nested classes is solved with a new release of the ASP.NET MVC RC.
Thanks to some very fast response from Phil Haack I’ve got to know about a new release of the framework. Here is the link to the RC II of the ASP.NET MVC.
Worked fine and as I said solved my problem.
When you learning something new you’ll expect some progress and the occasional setback. If you are on your own, as I am in this project, that is even more likely to be the other way around.
My approach to learning this is very much like the way we played with the chemistry box when we were small – try something you believe will work and expect the whole thing to blow up, possibly with a stinging sensation to your eye…
So… I guess that you see where this is going. I have to redo something. Actually it’s two. And actually I am not that worried; the whole idea of agile TDD, DDD and all this is that it should be easy to change.
The first thing is not biggie; my Entities has a Guid as ID right now. It’s mega-ugly when I am passing it around on the querystring etc. I’ll change that into an integer. The nice thing about Guid’s is that they are guaranteed to be unique. But not very human friendly…
The second thing is a more delicate matter in DDD. It has to do with aggregates and something called aggregate boundaries (which I understand as: “where do I stop, the whole database is knitted together…”). This post, by Casey Charlton, explains the background in a nice, compact way. Actually the whole site rocks, with a the relevant posts as a book even.
For me Jimmy Nilsson summed it up in a nice way:
The parts of an aggregate have no reason to exists without their parent.
In my case I have the Product-class that contains a ProductBacklog which is a list of ProductBacklogItems. The ProductBacklogItems have no reason to exists without being attached to the Product. So the Product is my aggregate root.
And as far as I understand (here comes the chemistry box part :)) it should be no ProductBacklogItem-repository. Add how to add a ProductBacklogItem to the ProductBacklog should be an operation on the ProductBacklog.
When the whole Product (aggregate root) is saved the repository will have to save all parts of the aggregate. Which can be quite tricky in the update-case I presume, if the aggregate is big…
Seems like I will be learning how tricky in a while. On to the code!
[Some time passes by while Marcus is coding…]
Eeeh – that took much longer than anticipated and I will stretch this session over two sessions. The main reason for that is that was forced to invent some kind of auto-increment functionality for my fake repository. It was quite simple when I had it figured out. I simply rewrote the add method into this:
public void Add(T entity)
{
if (entity.ID == BaseEntity.NEWID)
{
// get the new highest id
entity.ID = FindAll().Max(x => x.ID) + 1;
}
dictionary.Add(entity.ID, entity);
}
But I still have the Update-functionality for my Product aggregate to figure out. More simple tests, please.
[Again some typing, head scratching and thinking takes place…]
Ok – that was much easier than I thought – which of course have to do with that I have a in-memory implementation of the repository right now… So the very simple Update-method:
public void Update(T entity)
{
dictionary[entity.ID] = entity;
}
… took care of it for me. It will probably be a bit more advanced when I have to map this to a relational database.
OK – but now I can create new product backlog items.
Great progress today – I’ve learned a lot about DDD today.
OK – here is one of the nicest and probably best trombone players in the world showing of his amazing technique.
Follow this link to a short clip from SVT where a couple of musicians competes in playing the Flight of the Bumble Bee. In Swedish… The whole program can be found here.
Amazingly Håkan plays the piece 20 beats faster than for example the violinist… And very clean.
Thanks for the lesson Håkan!
I am now almost ready with the first user story of my own backlog.
1. As user I can create a product that describes the product and the product owner so that the purpose of the product is known.
Each product has a product backlog that describes what is left to do.
Each product backlog item requires at least an Number(1.2.1), description, initial priority.
Other properties are story points (how big is this compared to other) and a document with additional business rules.
The one thing that is left is to be able to create new backlog items.
My GUI for editing a product right now looks like this:
and as I said before I will not put to much effort into the design of the GUI, but I have noticed that the MVC-pattern opens up for GUI-design decisions to be change later on. I mean – there is a product backlog item create action that can be outputted as a pop-dialog or on a own page or via AJAX/Flash or …
That is a really nice feature.
Come to think of it – this is one of the main thing of DDD. You are given the freedom to choose (and change) how to solve when the time is right. This goes for all the ends of the application design; the database and the GUI for example.
The important stuff (ie. the model) is what you need to worry about.
OK – on to the code! Lets write some simple test…
I brushed on some extension methods today. They are cool but a bit messy since they don’t belong in the class they are extending… I am not sure if I like them or not.
I came as far as I could create the form for creating new product backlog items. Tomorrow I will save them.
PS. Passed 100 unit tests today. Yeah!
As I wrote earlier I have been away from Stockholm for a few days. Me and Abbe (and my father in-law, of course) went on a mini vacation at (in?) Hyppeln in the Gothenburg archipelago.
The weather was wonderful and we got some really nice days, with a sniff of summer-feeling...
[UPDATED]
This is solved. See this.
I ran into this problem:
I appeared when I added an Edit-view for an inline view-data class. That is; I have created a special class to hold the view data that the controller is acting upon, and that class is declared inside the controller.
When the Add view-dialog (which I love by the way) of the ASP.NET MVC closes with OK – this dialog appears.
I think that it’s a bug in the RC-release but I am not sure. I’ll send this to the ASP.NET MVC team and see what they have to say.
I am not sure that I will have the view data class as part of the other class since that violates the Single Responsibility Principle (SRP) – but if I do I get this crash.
The more reason for me to move it then! I’ll do that…
I don’t think I ever been doing system development in a nicer place – I am right now in Hyppeln in the Gothenburg archipelago. The weather is most wonderful and we have actually been sitting out for coffee and even managed to do some barbecue…
OK – I am pressing on with the Edit controller action for the Product. Ran into a bug of the ASP.NET MVC framework I think. The first one I see – pretty good for a RC…
I think that I have missed some part of the TDD-ing with that I haven’t been good at “testing my boundaries” (a Code Smell from Clean Code by Robert C. Martin). When I read it I didn’t fully understand it but as I am beginning to understand the TDD-ways I realized that for most cases that is to write tests for the NULL-values also. I guess that you could go to the other extreme and write test for the highest possible value but I cannot see the great use of that. NULL values are always good to test for so I think I will incorporate that into my TDD rhythm, and maybe even start with it.
Today I have worked with the Edit (update) and Delete-actions. I have implemented them in the view and the controller, still with a very simple UI.
I actually got the Product Backlog Items in a usercontrol also. Found the really nice RenderPartial-method that renders a user control in a view.
I have a great feeling of “i have done this before” when doing the UI. It feel likes good old ASP.OLD done right. And a bit like Web Classes (IIS Applications in VB6 back in the days). I like it!