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...

Bil Simser has stepped into the complexity debate with this post.

This is actually on the end of Bil's post, but it deserve a special mention:

In that, I haven't done justice to the P&P team. Introducing Agile methodologies and best practices is something that I am very passionate about, and I failed to give them their due credit about their efforts in this direction.

After you have built one application like this, you can extract the relevant parts into a "framework", although I am not sure that I like the term. The main difference being, again, that this is something that is driven by a developer seeking to make life eaiser, not by BDUF.

The end result is often a purpose fit framework that is very easy to work with, and doesn't require years of study.

Not really, the basics are deceptively simple, but then you are going to hit a lot of issues with dependencies cycles, life time issues, etc.

Not really, I would tend to use best-of-breed stuff that I would have available, it would cut the stuff that I would need to build by 60% at least. But I would not build the EntLib by any means, I may have components that have similar functionality, but in general, it would be a set of services, not a framework. Jeff Brown had a good post about the difference between the two.

The first part and last parts of the sentence conflict each other, fairly badly. If they are so complex, I would get much better ROI than rolling my own, or (more likely) reusing stuff already built that isn't so complex.

Don't you think that this is an issue when you can't get the basic concepts of a framework in an hour without drowning in the details? Apples to oranges, but I can show a MonoRail application that has nothing but the basics, and talk about that and the concepts underlying that. If the technology is obstructing the end goal (creating maintianable applications), how is it useful?

Well, considerring that Frankenstein was a very smart doctor, probably a good one. I think you meant something else, and I am getting tired of answerring that statement, frankly. Using several components together is neither cobbling nor frankenseining nor hobbling a solution, it is using the best attributes of each to achieve a cohesive whole. The end result of a highly componentized architecture is... good design.

This is were all the trouble start. I am explicitly not saying that the P&P guys did a bad job, I am saying that I don't believe that the direction they are pushing is the right one.

Bitchy: Feel free to try to deploy P&P's DAAB without Microsoft.Practices.EnterpriseLibrary.Common, when you are successful, then you can complain that NH has a dependecies.

Seriously, NHibernate.dll has dependencies on several assemblies. And it follows separation of assemblies, so if, for instance, you don't need the 2nd level cache, you don't need the MemCached assemblies deployed.

You get that with everything that you use, if it bothers you, use ILMerge to make this a single DLL, and then forget about it. Disk space is cheap, and it is really not an issue. About the previous point as well, you can merge log4net into NHibernate if you so like, and get rid of the extra dependency.

I seriously doubt it. A good collection of tools would enable you to write clean, intent expressive code. I don't think that you would end up with more code, if anything, the lack of designer generated code would reduce the amount of code that you would have to deal with.

Patrick Cauldwell has a post about a set of guiding principal, which I mostly agree on, except:

There is a couple of things here that is missing, that is business need and evaluating fitness to do the job. I am pretty sure that Patrick didn't mean to sound this way (by the rest of the post, he & I could argue for a few decades on the fine details, but I mostly agree), but this sound like an approach for a tech driven disaster to me.

I have seen technological solutions crumble under their own wieght, because their fitness to the business problem was never really considered. "It is MyNewThing, of course it can handle this easily, why, it can handle ten times this load." - But you forgot that scalability != perfromance. The end result was a failed project and a poisioned relationship with a customer.

Perhaps the only thing that I would add to Patrick's statement is: "When it makes sense to the business problem at hand..."

It is out, although I have yet to hear the edited version, the real discussion was very interesting.

Go check it out.

Several times recently I had to created what is basically random assoications between two sets of tables. The problem is usually trying to get some data for the UI. Here is what I came up with:

The only interesting part is the where clause, since it forces SQL Server to evaluate the statement on a row by row basis. This has horrible performance, by the way.

From the Hibernate Blog:

You really have to read the whole thing to get the spirit of the thing. ROTFL.

Oh, and the message isn't that bad either, I had similar discussion with Ted Neward on the OR/M Smackdown.

Via DotNetKicks, I have found this post, which talks about how you can use XmlHttpRequest from SQL Server. I have to bow to the creative power of Dave, but this really frightens me. Next thing we will have a new fad.