To some extent the book works especially early on. In fact even in chapters 6/7 its covering the issues I want to know about but I’m always left thinking “Yeah but what about..”, “Nooooo, don’t stop there…”, “Hold on, how does that solve the problem”, “Well he might mean this, or does he mean this” or whatever.

That’d be fine if I was reading a theoretical text but not with this book as it really doesn’t cover much theory. In fact I almost think I’d have enjoyed this book more if I wasn’t using it whilst trying to work in a domain driven manner, because I probably wouldn’t have noticed that it didn’t have the details that I’m interested in.

I guess I might stop reading it and will come back to it in 6 months once i’ve been doing more DDD/database development and have read the book by Eric Evans.

Actually Dave Hayden makes a good point:

That being said, I think the market is ripe for a person(s) to author a book that expands upon Jimmy’s ideas. A book that implements and discusses the following design techniques mentioned above into an actual executable application using open source tools like NHibernate, Spring.NET, NMock, NUnit, etc., would be the icing on the cake and a sure winner.

I agree with most of what you said but I’ve also found that the later sections have their own troubles.

I read through the first 100 pages quite quickly, I’ve read about TDD/refactoring before so wasn’t that interested in this part (Robert C. Martins book has great coverage of the TDD cycle).

I then got into chapter 4 which was good, chapter 5 was also quite interesting so I was beginning to enjoy it.

However I think things took a big down turn in chapters 6/7, and I think its because the style changes as there are less code examples and things are covered at a higher level. Instead of discussing the process we end up going directly to the solution (Jimmy indicates this is what he wanted to do). However this, and the writing style, causes me problems for a few reasons:

1) In many cases I don’t understand what Jimmy is saying, I’m almost embarassed to admit it but its true :)
2) Even if I think I understand the text is vague enough that I’m not 100% sure that I’m correct, especially given that the wording/English used can sometimes lead to misunderstandings.
3) The devil is in the detail and the most interesting sections lack detail. I’d far prefer if the first 100 pages were cut and chapters 6/7 were really fleshed out.

I agree with you completely that lots of questions are asked without the answers being provided, or the answers are given at such a high level that its difficult to work out how you’d apply them. I know the author is an expert so I’m finding it quite frustrating.

I also agree that the overly personal style begins to grind after a while, atleast for me. I think part of the problem is that before starting this I read Robert C. Martins excellent Agile Principles book and the styles of the two authors couldn’t be more different so I went from reading one book that I really enjoyed (partly due to the excellent examples of everything that is discussed) to another that I’m finding to be a real struggle.

Oh and I agree about “.NET Framework Design Guidelines” being superb.

[)amien

I really appreciate your feedback! Thanks!
:-)

When I revise the book I will definitely take them into consideration!

Best Regards,
Jimmy
http://www.jnsk.se/weblog/
###

1.
Factory classes imho should be static because I don’t want to create a new instantion of the factory classes each time i need to call the Create method. If you need extensibility you could apply the Provider design pattern by adding the provider to load in the config file and then in the type initializer of the factory class load that provider and each time you call the Create method you delegate the Create to the loaded provider.

2.
What Jimmy meant by making the IList read-only was to make sure that the IList does not get replaced by another IList but instead IList manipulation is controlled through seperate methods

3. Expose internals for testing!
This is called “Friend Assemblies” [assembly:InternalsVisibleTo("")] a commonly used technique for unit testing.

4. Coding standards
The coding standards are guidelines whether you follow them or not is merely a matter of taste. There are a lot of examples in the MSDN Library where the coding standards are not respected either. Furthermore in a lot of companies they use their own coding standards so I can imagine that people use different coding standards.

I agree that that some of the points Jimmy makes in his book might seem awkward I do still appreciate that he wrote the book.

Let me know how you get on with the book – I’d be interested to know if I missed/didn’t get some of the good content out of it.

[)amien

Two observations from my side though:

The public fields; Jimmy says they’re fine if the implementation will never change, according to your comment. So you’ll never break binary compatibility! :) But still, I’d prefer properties over fields. And in VS2005 the “prop” smarttag rules :)

And about the coding standards; I still use _ for internal members, because it’s more clear what you’re using, class or method variables.

Oh, gotta go :)