The question was not rhetorical. I too opt for option b). As for the comment plugin, I am using the free wordpress blog right now which affords me very little in the way of customization. I am working on getting hosting for my own sight. Its just hard to find the right place since I want SVN on the server along with other options.

I’m not sure if your question is rhetorical, but I would go for option B. The command chooses which delegate to use. If you have multiple views each with logged in/out checks (as in option A), that would be code duplication. Having one command manage it seems simpler in my opinion.

But then again there is a time and a place for everything! Maybe option A would be better in special circumstances.

1. Yeah, I think there is a point when you should consider breaking a command down into smaller bits. How that is approached is innumerable. I would make the assumption that if there is a whole bunch of logic in a command somewhere, then there is a high chance that some portion of the logic is or could be handled elsewhere and be reused by other commands or classes. No point in code duplication. But generally I would rather have the logic (if it isn’t being reused) to be in one place which is the command.

But let me pose this to you: You have an application that saves data either to a local shared obj or to a database. Where it is to be saved is determined by seeing if a user is logged in or logged out of the app. The logic for sending the data is the same in either case. So do you A) have the view see what the log in status is, then call an appropriate command such as saveToLSO or saveToDataBase? or do you B) have one command that chooses the appropriate delegate and has just one place for the needed logic?

2. I generally like the idea of having less places to go and more to do than more places to go and less to do. Meaning, I’d rather have a delegate with half a dozen related methods than half a dozen related delegates with one or two methods. But both approaches would be acceptable in my book.

Personally I like to pass VOs into Views, then have the view do what it wants with that data. I prefer this way because it makes life simpler if you want to add a variable to the view. Rather than having to create new setter/getter functions, all you do is add a class variable to the VO.

So each of my Views has data encapsulated in a VO. The view updates the VO as necessary, then sends it via an event to a Command. There the Command can inject data or simply pass the VO to a Business Delegate.

I have two more questions which I would like your views on:

1. Is there a point when a Command contains too much logic? In this case, should helper class be created to assist commands?

2. Say I have one HTTP service that can perform different actions based on paramaters based to it (e.g. mydomain.com/getdata.php?action=action1 and mydomain.com/getdata.php?action=action2). Should I create 2 Business Delegate classes, one for each action? Or should I just have one because it is essentially the same service. This becomes more complicated when the service performs, say, 10 actions. You end up with 10 methods in the Business Delegate, one for each service action. Is this acceptable?

What do you think?

Of course this too doesn’t sit well with me because then you are only utilizing the ValueObject through one data transition. In addition to that last point, I really like the idea of utilizing ValueObjects for more than parameters to be passed to calls.

Take for instance a view with several controls (2 comboBoxes, 5 text fields, etc.). I really like this idea of having a getter/setter property that takes/returns a VO. This way when setting that property, you can pass that VO to the view, which the setter looks into to set various more granular properties (such as the aforementioned controls). The reverse could happen on getting that value, the getter looks at the granular properties of the controls then returns a VO based on that. From there it could be bounced around or sent off via a call.

Who knows. Maybe this is the standard in which things work and I have been in the dark. I just know that this is underutilized in the projects I have worked on in the past.