Constructor Injected Dependency vs. Setter Injected Dependeny

Just a thought: I always felt more comfortable with CID than with SID, but that was really just a feeling. While I was reading some code, I realized that with CID there is no chance that a dependency will show up in the interface, because interfaces don't have constructors. So the dependencies of a service are much better hidden from the clients of the service.

Of course one could separate the service interface and dependency interface and I would do just that if I couldn't go with CID.

Which leads to another interesting topic: In what situations is CID not working?

Off the top of my head I can thing of the following situations:

• Legacy Code: Obvious! You would be lucky if that stuff used Dependency Injection at all, so do not get greedy!
• Cyclic Dependencies: That should be avoided anyway, right?
• Optional Dependencies: Not really. I would rather inject a default implementation (e.g. something like a Null Object).

Right now I can't think up any more scenarios.

del.icio.us Tags: IoC, Design, Patterns

One more R# shortcut I didn't know about

I do use the R# shortcut Ctrl+Alt+F for reformatting code very often. But the dialog that shows up then asking me to confirm options I have alredy set allways puts me off.

When listing all available shortcuts for my VS 2005 with this very neat script, I found

Ctrl+Shift+Alt+F

which is "SilentReformatCode".

BTW: Does anyone know what the EnableDaemon command is doing? (Ctrl+8)

When it comes to NHibernate, dates are no fun!

I just stumbled on some nasty behavior. While preparing some presenation on mapping existing schemas with NHibernate, I was using a mapped version of Northwind to do some queries.

I queried all the Customers with all their orders. As usual I was doing this in a transaction and expected that nothing would have changed, so nothing would be written back to the db. Nevertheless an exception of the type Data.SqlTypes.SqlTypeException with the message "SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.".

What had happend was this:

The Order contains a nullable column ShippingDate. I didn't map that column as a Nullable<DateTime> but just as DateTime. When NHibernate reads the row from the db, the value is null, and that's what the session remembers. When the Order object is rehydrated by NHibernate the ShippingDate is set to the value DateTime.MinValue. When the Session is synchronized with the db, NHibernate assumes that something has changed, because the currentState and the previousState are different and tries to update the row. Wich in turn fails, because DateTime.MinValue won't fit into a SqlServer datetime column.

I was lucky I could just inject my "StopHereForDebuggingInterceptor" into the session to look at what was happening. Mapping the Field as DateTime? solved the issue. I wonder if the descicion to map DBNull to DateTime.MinValue was a sound one.

Underscores are terible, but_I_still_use_them

I must admit, I get the creeps when I look at some code and see unterscores used all over the place. It's so old school to me. And it has been my (lame) excuse for a while for not digging deeper into the Ruby language.

But there is one place where underscores make sense: Naming your unit test methods! It is just good to write somthing like

When_user_enters_search_term_longer_than_three_characters_Presenter_fetches_matching_products

Unfortunately it is a PITA to type such as thing. Today I came accros a really good idea from Jean-Paul Boodhoo while watching a dnrTV screencast. He has build himself a Visual studio macro that just picks up the current selection and replaces every space with an underscore.

As I was sitting on the train while watching, there was no way of downloading this macro (and I'm not sure if it can be downloaded), so I had to role my own and here it is:

Sub MakeCompileableTestName()
    DTE.Find.FindWhat = " "
    DTE.Find.ReplaceWith = "_"
    DTE.Find.Target =
vsFindTarget.vsFindTargetCurrentDocumentSelection
    DTE.Find.MatchCase = False
    DTE.Find.MatchWholeWord = False
    DTE.Find.MatchInHiddenText = False
    DTE.Find.PatternSyntax = vsFindPatternSyntax.vsFindPatternSyntaxLiteral
    DTE.Find.ResultsLocation = vsFindResultsLocation.vsFindResultsNone
    DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
    DTE.Find.Execute()
End Sub

It seems to work nicely and I have assigned it to the Ctrl-Shift-Insert Keyboard shortcut.

Patrick Cauldwell's Blog - This I believe... the developer edition

I came just accros this on Scott Hanselman's Computer Zen: Patrick Cauldwell's Blog - This I believe... the developer edition. and I am about to discuss it right now with my team (the ones that are just picking up .NET development). I think that is a really good starting point.

C# Regions Suck

The more I see of it, the more I firmly believe that C# regions are not a good thing - at least if the code has been written by some human.

I was just listening/watching a screencast about the CSLA Framework on dnrTV and Rocky and the other guy just drool about how cool regions are when looking at one of the CSLA example classes which has around 441 lines of code and 6 regions and 23 methods which do such diverse things like validation authorization, instance creation, data access, existence checking and even some so called business methods, that more or less are just getters and setters for the data behind an object.

Back to my heading: The regions in C# (not sure if there is such a thing for vb.net) are used to give some structure to a class that is doing to much. This seems very much like a GOD OBJECT that should be torn appart along the lines of the SINGLE RESPONSIBILITY PRINCIPLE in the first place. Using regions here is just window dressing.

Btw: The CSLA is doing some interessting things, but I still do not understand why it does those things so clumsily.

The following code shows an example of how CSLA is checking that the current user can read a data value from an object.

public object SomeProperty {
  get   {
    CanReadProperty(true);
    return _someProperty;
  }
}

So there's the security concern intermingled with the rest.

If the member where defined like this

public virtual object SomeProperty {
  get   {
     return _someProperty;
  }
}

it would be easy to have a decorator arround the object that is taking care of the authorization, so the security aspect would be out of the business code. If you used something like DynamicProxy , you could make the security aspect even generic (not like in Generics) by introducing an Interceptor that handles all the property access with the same logic, maybe using Attributes to declare who is allowed to access the data.

For me its the end of the Gui Architectur Confusion! Presenter First rules

After reading about GUI architectures here and here and after being in a project where the GUI layer has been architected by a real architekt (as in "over 40 and over confident") into an unusable mess, I believe I've finally found the holy grail. For me it is at least. Look for yourself at this and make up your mind.

The even have a notion about what I have called The User as a Service every now and then.

What is the best thing about Presenter First, is that it not only takes into account architecture but also the actual develoment process and it is a perfect fit for TDD. And Presenter First seems to be a very good addition to DDD.

I came accros this by looking at the most unlikely place to find something that is so simple and so elegant and looks so feasible (not to mention that you can do it without software factories, domain specific languages, code generation (well the authors actually use some code generation but it is not needed), visual designers) at ARCast on Channel 9. They have two episodes

• ARCast.net - Presenter First Pattern (Part 1)
• ARCast.net - Presenter First Pattern (Part 2)

My advice

• Read the papers
• Listen to the podcasts
• Look at the examples
• Try it in your project
• Be happy!