- It was designed to be a defect
- I have too much exposure to security issues
You have to follow the discussion to understand that.
@Glenn: Someone posted a reply on my blog about the guidance package:
"I don't really like what they did there. Having views like IContactDetailView puts the model into the view which is exactly what you are trying to separate. IMO Views should be things like Grid, Spreadsheet, Detail, etc which can handle any domain object (Contact, Customer, etc)"
That is the Extremely Passive View.
It basically says that a view is the base control, and you need to handle that. A view IMO is the presentation required for a certain business scenario. IContactDetailView is a business scenario, and as such it is appropriate.
Coupling the Extremely Passive View with a very complex RowDataBound handler results in my favorite presentation pattern:
That had me in stitches, and no, it is not a typo:
I read Ayende's blog rabidly
From the Castle Dev Mailing list:
Ken Egozi: When someone would build a generator that can generate a domain model by listening to a white-board design meeting, that would be a craic.
David Marzo: There is already one -> good software developer ;-)
This quote from Scott Bellware had me ROTLing:
In .NET, the UI tools are object-oriented and the middle-tier tools are procedural. This strikes me as a touch absurd.
I certainly concur.
Read the rest of the post, Scott is answering comments from his previous post about using Ruby on Rails. Very interesting.
Some random quotes from yesterday:
- Benchmarks are really inefficient way to gauge performance
- Put a drop down list around this table, it is doing too many postbacks
- Debugging multi threaded java script
What caught my eye was this quote:
I agree whole heartedly, and for much more than merely SOAP or Web Services.