Just to reference a great article about using NHibernate & WCF, worth checking out.

Quite a few parts of NHibernate are serializable. ISession and ICriteria are of particular interest to this post. Serializing the session (neccesiate that the entities are serializable, of course) is very useful for the Session-pre-conversation mode. But it is the criteria that I would like to talk about right now.

Criteria in NHibernate is the OO interface for making queries. So, why is it important that it is serializable? Well, it opens up some interesting scenarios. Saved searches or reports are just one of many. I have used similar functionality in the past to build a rule engine, where saved criteria where the basis of selecting what a rule should process.

The only problem with that is that you usually want to display the query to the user. I have recently added inspection capabilities to the criteria, but they are focused more on infrastructure stuff rather than ease of extraction for the UI. For those cases, you might want to add a way or the UI to restore itself to the appropriate state for the selected search.

Okay, here it is. This is a little diferent style than the one I have made before. This isn't scripted at all. This is literally a recording of me trying to solve the Event Broker issue. As I have mentioned, I have spiked the issued previously, but not in any serious manner.

As a result, you can see me stumbling over issues in the implementation, and it is much less professional sounding. It turns out to be less than one hour recorded (+ 5 minutes spent checking the Rhino Mocks source code "off stage"), and I think that I have a good solution for the Event Broker issue.

I am afraid that at times I have been reduce to unintelligable muttering at time, but I hope that it is still valuable.

Stuff that is covered in the screen cast:

• Event Broker
• Declerative Event Wiring
• Registering to events from classes we don't own
• Avoiding memory leaks

The code starts at 2:30 minutes, and it is pretty much just code (and my mumbling) from then on.

As usual, the code is supplied, and the download page is here.

I think you can pretty much understand how I feel about this feature.

Think about it, a compile time only method declaration, that you can "override" in another method, like this:

The crazy part is that the code below is not compiled unless you supply an implementation to the method, and the implementation is not neccesary.

The reasoning behind that is to have light-weight events, that exists only when you "subscribe" to them. The reason for that is the Linq code generation features, which produce a lot of events.

So, this is basically compiler macros again, for a dubious reason at best. I don't think that the language should change because of a tool that it using it. If they want to make any useful changes, there are more than enough suggestions. Method Missing would be welcomed, as well as attributes that can accept useful parameters (i.e, not just String, Int32, Type).

Yuck!

Yes, this is another response to Sam's post, and this time is has nothing to do with the CAB or P&P. This is about a few things in Sam's post that really bothered me:

• Let's leave out the fact that three of my best friends in the world designed and implemented CAB. That's just the personal stuff. My problem is simply that many of the assumptions and things they wrote are patently false. They don't know these people, they don't know CAB at all.
• But what I object most is how they are targeting the wrong team in Microsoft! The P&P teams are one of the ONLY if not the ONLY team(s) in Microsoft that do Agile XP.
• Here's a group trying to spread the good news of Design Patterns/Fowler, TDD, Agile and Iterations, etc and you have to stick it to them?

So, let me rephrase that.

If:

They are your friends and they are doing agile, TDD, XP, etc.

Then:

I must not criticise what they are doing, even if I think that they are doing something wrong.

I am all for Agile and TDD, and I love to see people using them, but I don't think that this makes them automatically successful, or that they will choose the best approach. And I am certainly not going to let the fact that someone is doing Agile or Open Source, or something else that I also believe in, to stop me from telling them that they are wrong.

I think that the P&P team is going in the wrong direction, I can see why but that is not relevant to the discussion, that they are agile (or Sam's friends) is not an issue, I still think they are wrong.

Probably because he has a point. He took issue with my statement about the CAB, being too complex for the job it is supposed to do. Perhaps the thing that I regert the most is that I don't have truly constructive criticism to offer in this subject. I can understand why "I don't think that this is good" can be seen as offensive.

Before I respond to Sam's post, I would like to mention that I do believe that we can have a reasonable discussion without attacking each other, even if I decide to offer criticism. I would admit that not offering a constructive criticism is a problem in this case, but I don't have anything valuable to suggest about improving the product at this time.

In addition to that: I don't like personal attack in response for a technological discussion, and I really wish that the discussion would not stoop to that.

Now, to the part where I try to answer Sam's points. This is addressed specifically to Sam.

I am sadden to hear that. I have some snippy remarks to this, but I would try to refrain from that. I would like to mention two things. I do believe that I am not talking empty words. The second is that while Israel and the US may have superficially similar cultures, there are many changes between both culture. Oh, and I am also narcissistic & opinionated jerk.

Sigh, why do people assume that I don't deliver business value to my customers? If I wanted to sit in an ivory tower and write frameworks, I could do it. I am pretty sure that I could get paid for it. I hadn't any complaint from any of my customers (or my boss) about using work-time for doing frameworks-in-the-sky.

A bare bone OR/M implementation takes about a day to write, Fowler has the basis in PoEA. If that was all an OR/M had to offer, I wouldn't really bother with an existing one. You can check here to find what are the basic requirements for an OR/M. I estimated that as three months for me + 2 good developers to get to a version that other people could start developing on. Of course, that is a fairly rough estimate, so it may take more.

I am sorry if this is the way it came out. I am using this blog as a way to express my thoughts about software and development, not as a way to put down other people. I would try to give it some thought, but I would request the same from you.

Again, it is not the patterns that I am objecting to, and I think that the CAB has some good ideas in it. I am delighted to hear that you have been successful in implementing a CAB-based solution, and that it has worked for you.

Nevertheless, "We actually don't find CAB that hard anymore" - that is after over a year of working with it, right? I would say that it would have to be hard to use after that period of time. Incidently, this is not the only reference for about a year to get the CAB.

If you feel that your invensment in the CAB had been worth it, go celebrate it in a pub. I feel differently about the applicability of CAB to my projects, for the reasons that I have already specified, and I have yet to hear something that would change my mind or would actually address the question.

Ha? I fail to see the connection between the CAB and SQL Server, sorry. You would have to use hand puppets to get that throught for me.

I wanted to take some time to clear some issues regarding my previous post about the P&P. A lot of people seems to grab on to my mention of CAB (interestingly, no one tried to defend the DAAB :-) ), and the conversation has turned that way. Just to remind you, here is what I said:

The only other thing that people seem to have noticed is the part about developing in vacum, but I will touch that separatedly. Since so much of the discussion has centered about the CAB, I am going to discussed it specifically. I would like to mention first that I have not built a real-world CAB based solution. I have listened to a few presentations on it and pursued the quick samples and the code itself, however. By no means am I a CAB expert, but I believe that I am able to evaluate the CAB and its ability to meet my needs based on that.

A lot of the discussion has been about the technical merits of the CAB, and whatever it is useful to use that or not. I have a few issues with the CAB from a technical point of view, but nothing truely major. I even said so explicitly in my previous post. I am not talking about the quality of the code, or whatever it uses the right patterns, or allows you to write testable code.

I am talking about the whole approach that the CAB has taken. This approach is too heavy weight in my opinion. My approach to big, complex WinForms UI application would basically consist of hierarchical MVC, probably with an Event Bus and a common base class for the Forms. If hierarchical MVC sounds familiar to you, that is very similar to the idea of work items. The CAB approach is to re-structure the entire application around the CAB.

It may be a personal preference thing, but I don't like it when I need to do something in a completely different way because of a tool that I am using.

About the complexity of the CAB approach, just a few quotes (hopefull not out of context):

• From Sam Gentile: "...I was going to show how to tame this CAB beast..."
• From David Hayden: "I have never had the pleasure of working with the Composite Application Block ( CAB ) or Smart Client Software Factory ( SCSF )"
• From Bil Simser: "I've spent the better part of a year learning CAB, EntLib, ObjectBuilder, WorkItems, and all that jargon..."

Complexity is not a good thing, especially when it is exposed to the user.

Developing in vacum:

This is another thing that some people took offence at is that I said that the P&P develop stuff in vacum. Sam Gentile don't think that this is the case:

That may have started out the proper way, but "working with dozens of customers" it not what I mean about developing in vacum. Perhaps a better word would be dog-fooded. As in, you build stuff that you will use. So you see all the pain points, and you find out what is needed in order to smooth the wrinkles. I said it explicitly in my post, I want stuff that people are incentivized to make great for the oldest reason there is, because it makes their life easier.

Now, please correct me if I am wrong, but I do not believe that the CAB team is also a customer of the CAB. That makes it development in vacum.

As long as I am stirring the pot, here is an amazing comment by Steve ( no blog, apperantly :-( ) left at Chris Holmes post about my P&P post. In reference to: "Would it be acceptable for them [P&P] to build Enterprise Library using Castle Windsor?"

I have no further comment to make, except that I would like Steve's blog.

I am a bit funny when it comes to learning technology, I read about it away from the computer, because otherwise there would be a lot of stuff that I would be doing that would interfer with the process of actually reading a book. Anyway, I am reading Agile Java Development right now, and I got to the point where the author shows how to build a simple page.

The sheer amount of steps required is scaring me. What is more worrying is that the author keeps saying how simple this is compare to other approaches (which I presume Java guys would be familiar with). I keep comparing it to MonoRail + Windsor, and I can't believe that this is so complex.

From an architecture point of view, it is very separated, but from an implementation point of view, it looks messy. Here is the piece of code that caused this post. It is meant to put the current object for the request in the context:

I am not a Java guy, and I never did anything beyond an applet in Java, so I may be missing something, but is this considered to be a good form of writing your code?

Issuses that I have with the code:

• Dealing directly with the request, extracting inputs, going to the database, etc. Those are infrastructure style stuff (and fairly repetitive, I would imagine). I want my controller to deal with business use case.
• The whole model seems to be based on overriding specific methods calls, while I appriciate the design, to me it seems like it unnecessarily complicating things by moving related functionality to separate methods, when it could be in the same place. (The timesheet object returned from this method is passed to another method down the line, for instance.)

Am I missing something?

(Hm, angering the Java people, angering the P&P people, all I have left now is to anger the Ruby guys and I am set. I shouldn't worry about that, I have a safe place to hide, Cell #6.)

Just spiked a test implementation on an Event Broker (similar to the CAB), basically support for loosely coupled events / commands. Took about... 40 minutes :-)

My understanding of the functionality in the CAB is based around:

• [EventPublication], [EventSubscription]
• [CommandHandler]

As far as I can see the separation between the two is main artifical, and based on whatever this is your code or a third party. Since both rely on events as the underlying mechanism, I don't see a reason to separate them out.

Biggest issue: string equality is a bummer.

I might do a live coding screen cast, showing how it can be done. Tried it now, but it is 2:28 AM right now, and I sound like a drunk sailor. I got tired of apologizing of slipping to Hebrew, and cut the recording.

That 40 minutes mark is starting to freak me, to tell you the truth...