OK – this was almost driving me crazy.
For demonstration purposes I had used the automapping feature of Fluent NHibnernate. In a very standard way – I used all of the conventions out of the box.
Except… I forgot to check the conventions. For example for primary keys the convention is to name it Id. Exactly that! Not ID or id or anything.
I ran into this problem when I tried to re-open a solution I did a while back when labbing with Fluent NHibernate and SQLite.
Behind the cryptic error message lies and easy solution; I was running the 32-bit version of the SQLite-driver and runtime. That' doesn’t fly on my Windows 7 64-bit machine.
Here is a more through description and here is a link to the latest version of SQLite that will get you all the version (32 and 64 bits) of the SQLite.
I’ve been playing around a bit with ASP.NET MVC and StructureMap (an IOC container). It all looks very nice and works wonder. During this I ran into an excellent blog post by Elija Manor on wiring StructureMap and ASP.NET MVC together. Beware of the favicon-problem though.
Again – i use NHibernate and Fluent NHibernate which so much nicer than the XML-stuff. The critics to Fluent NHibernate says that you cannot reach all functionality from Fluent NHibernate, but here is an example on how to set specific properties in your configuration. Helped me through this example.
Also found some great code examples from the TekPub NHibnernate series here.
OK – I've added “TDD?” in the title. I love TDD and it’s my preferred way of doing code, but I have a problem (to quote a thinker). I think TDD doesn’t help my through the broader strokes of my application.
Where do I start? How do I use the test to know that it’s time to add an repository, or an IOC Container? Do I TDD the IOC-code?
I asked the Swedish ALT.NET group a question and got some great tips, mostly they pointed me to BDD and those ideas. I also liked the idea of the Walking skeleton.
But I’m still confused. Can TDD really help you to design a system from the bottom up, or top-down (BDD) for that matter? Will the design be improved by the TDD-design technique? I’m not sure.
For now, my thinking is that it’s better to create a very simple design (MVC + repositories + IOC) to get your “skeleton to walk”, maybe with a functional/integration test that verify the functionality.
With that foundation in place it becomes easier to add some meat to the bones (is this skeleton metaphor taken too far yet?) with the normal TDD techniques and patterns.
The last day kicks off with a keynote given by Scott Hanselmann, who is one of my "heroes" if you like. I always wanted to see him live, he is usually informative and really funny. Here is some off his tips on the subject:
This was very funny and informative. The funniest is that he did basically the same as the Zen-guru Marc Lesser. But oh so different…
This promise to be great. The first slide says “How to teach pair programming?” It looks to be, just as the title, as a show. With props and the whole thing – nice. The presentation is done by Niclas Nilsson and Hans Brattberg
Also they promise to show some of the bad things that we can experience when teaching/learning pair programming.
Pair programming is about; communication, learning and communication. So be patient, split time with keyboard equal, talk, not show. It’s hard! But the only way to get everybody up to speed.
Without an engaged navigator you don’t collaborate and share mind. Then you get any of the advantages of pair programming. A complicated operation is always performed with two doctors. Would you rather have one?
There are now giving some great points on why pair programming is feasible and economical. For example this chart.
It’s easier to stand up for code quality and not “hacking” when you are two people together… Also it’s harder to hide technical debt.
They had an excellent summary slide of benefits with too much for me reloop here.
This talk is given by a tired Ayende. He has promised to use his designated victim method… Better stay alert.
He talked about the use Dependency Injection, Inversion of Control containers and Convention over configuration to manage solution complexity.
Using a Inversion of Container will make us feel like you lose control of your dependencies. And that is the whole idea – if you micro-manage your dependencies will give you a static system that is hard to change (Open-Close-principle, open for extension but closed for modification).
Another benefit from using an IoC is that you get opportunity to use aspect-oriented programming, to handle cross cutting concerns.
Dan North – given a talk on not believing in efficiency (the theme of the conference) ;).
What he is aiming at is the difference in efficiency (the effort we burnt so far) and effectiveness (the outcome is what’s important, not how much we burnt so far).
OK – this is great! He is dropping gold ever ten seconds. I just hope to get hold of the slides, and try to post them here. I cannot possible summarize it here… It’s boarder-lining on politics but I like it.
Dan North – check him out. He’s great and quite funny also.
OK – best so far! By far!
This will be another talk by Stephen Bohlen, the speedtalker… So I don’t expect to be able to write to much during this.
We’re learning about add-ons (etc.) to NHibernate.
Here are some nuggets that I managed to throw down:
This was great but oh so fast, I’m short of breath…
Going into the last part of the day and I am beginning to feel tired…
OK – Juval Löwy is up now and I expect some pretty advanced stuff.
Yep – I will be some not so well-know productiveness things in WCF. Another list:
Another great session. I’m running out of batteries now. Not sure if I can document the last session… Maybe – I’ll publish now, just for sure.
Julia Lernman based her talk on the frustration on not understanding how to use it, from a developer perspective. Suits me just fine – I’ll learn all the cloud religion later… :)
This seems to be a great but basic talk. I’ll leave it and try to grasp it. I am a beginner on this…
Now it’s NHibernate with Stephen Bohlen, who is aiming to cramming in all (kinda…) of the screencast on www.summerofnhibernate.com in 4 hours.
I think I’ll just sit back and try to learn this, because this guy is probably paid by the word :)
OK – closing in on the end. I really enjoyed this presentation but it would have benefitted from being longer, a whole day. It felt a bit rushed and we didn’t get as far as I would have reached. Although the material covered was great and well presented. And now I always have the www.summerofnhibernate.com to run back to.
I learned something about TDD and unit tests. Always ask:
“What can we safely assert?”
And the answer should be:
“Only the values I’ve set in the test code”
This is especially useful doing “unit tests” against the database (ie. integration tests).
If you write a test that searches for people with first name equal “FIRST NAME”, the only thing you safely can check that returned people contains is that first name equal “FIRST NAME”.
Found a great presentation on the excellent S#arp Architecture framework. The presentation is given by Billy McCafferty who is the father of the framework.
It’s so good – you just want to start to code with it. It’s a bit “rough” but I suspect that we will see some major improvements in the “developer experience” in the near future.
Also – tomorrow Håkan Alexander will present the framework at Elevate. It will be great to see how the framework will be received among the Avegean. I would cast my vote on big success…
I ran across this post by Ayende and it pretty much sums up where I want to reach with my persistence ignorance efforts:
“After that, you are done. Just create an entity in the proper place, hit the /database/create and have a lot of fun.”
I of course like the fun-part of the quote the most. :) But seriously – that what I want to reach – to configure my conventions. And then simply code the model as I want it and let the framework (NHibernate in this case) figure out how to store it.
Well, as it seems, the Fluent NHibernate framework has been updated since the Ayende post. So I’ve read, and read, and read and discovered some shortcuts. By the way – here is an article on how to make the transition from the “old” convention-style into the new.
I have put together an updated sample for what Ayende did in that post above. I also added a feature to be able to automatically set cascades for OneToMany- and ManyToMany-relationships.
Here is the most important parts of the code.
[UPDATED]
Here is the complete sample.
Did I mention that I LOVE Fluent NHibernate? Well I do!
I have been playing around quite a lot with Fluent NHibernate lately and ran into this problem a couple of times.
What happens is that when you set up a mapping test with PersistenceSpecification<T> that tests a reference (with CheckReference for example), an exception is throw like this:
System.ApplicationException: Expected ‘Marcusoft.Product' but
got 'ProductProxy…' for Property 'Product'
This has to do with that NHibernate creates a proxy-class and doing Equality-test on that class. I have picked up a base class that “fix” this problem from the Hibernating Rhinos (my god! what a name…)
You can read about it here or read my code here.
After a couple of days in the Fluent-world I am taking to it as a fish to water.
One of the features that I am tried out and really think will be helpful is the ability to test your mappings. Especially nice is that you in your tests can switch to a in-memory database (with SQLite) so that your test run faster, and without having to setup a database.
I found a good introduction to NHibernate and Fluent NHibernate by the Hibernating Rhino Gabriel Schenker that also introduces mapping testing. Read it here (part 1, 2 and 3).
Love this quote by the way: “if you continue to implement your own data access code you are stealing (money) from your customer”
After my very short experience with NHibernate I have already come to realize that lots of problems can arise from and in the XML-files that contains the actual mapping instructions.
Just the fact that they are XML gives you the classical problem of no compile-time checking and the possibility of calling things differently in the code and configuration.
Well, here is the solution; Fluent NHibernate. Their solution is simple – do it in code, in a fluent interface-style.
I just ran through their starter example and I like it. A lot. And some of it is almost magic. A good way to “let the storage issues be a consequence of the domain model”
The more I work with it the more stupid I feel around what I have been doing before; why have I written so much SQL? It feel just … unnecessary. Who said stupid? Not me…
Jimmy Nilsson said something like; “I just want the database and storage problems to be a consequence of my domain model. I don’t want to think about it”. And that is one of the goals with DDD and the solution is, for example, NHibernate.
I have been doing some labs with NHibernate the last couple. And as often with me – I think I am in love. NHibernate really rocks. The mapping files are quite hard to chew off at first and I suspect that there are many tricks and traps for me to find. But still – so beautiful.
Of course the Net has helped me a lot on my quest. Here are some articles that I’ve used:
A bit on the sad side (or NOT) is that we were trying to create a Unit Of Work implementation for NHibernate. Not only has this been done before, but also apparently NHibernate hooks into the System.TransactionScope implementation of the .NET framework. Thanks a lot to the gurus of level 3 – Magnus and Calle who show me that. All my code – down the drain… :)
OK – this has been a great learning experience. If you want the code – drop me a line and you’ll have it in a jiffy.
// Open a new session to retrieve the just saved user
session = factory.OpenSession();
User joeUser = (session.Load(typeof(User), "[id]") as User);
// Update a property
joeUser.LastLogon = DateTime.Now;
// Flush the changes back
session.Flush(); // The database is now updated!!!