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

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!