I am hoping we can all agree that there will be cases a generic UI will be suitable and possibly the best choice, and cases a handwritten UI will work much better (or even be the only suitable option). That is what I like in RO over the vanilla NO approach: it provides most of the benefits of a domain first approach, yet it works great with a handwritten UI as well.
Cheers, Rafael On Tue, Aug 14, 2012 at 12:07 PM, Dan Haywood <[email protected]>wrote: > On 14 August 2012 12:15, Mark Wood-Patrick <[email protected]> wrote: > > > In > > > > http://en.wikipedia.org/wiki/Naked_objects > > > > It says: > > > > Naked Objects is commonly contrasted with the model-view-controller > > pattern. > > However, the published version of Pawson's thesis (see References) > contains > > a foreword by Trygve Reenskaug, who first formulated the > > model-view-controller pattern, suggesting that naked objects is closer to > > the original intent of model-view-controller than many of the subsequent > > interpretations and implementations. > > > > > > I'd like to understand why folks question whether Naked Objects paradigm > > follows MVC and where they believe it does not follow MVC, anyone know of > > any such references? > > > > > That text in wikipedia was written by Richard Pawson, who was attempting to > point out to various nay-sayers of the naked objects pattern that NO is > very much in accord with MVC. I can't give you any specific references > though - that text was in the very first version of that page (Aug 2007). > > An early criticiser of NO was Larry Constantine, who wrote an article "The > Emperor has No Clothes" [1]. He is a usability / UI specialist, so > obviously the idea of an auto-generated UI was anathema. > > There hasn't been much other coherent argument against NO though, that I > can recall. But in years gone by we must have handled things very badly, > because these days if I see anything about NO at all it tends to be > negative. A couple of recent tweets in response to the RO article we put > up on infoq [2]: "the naked argument was beaten to death on the DDD list a > few years back. annoying that it's back again" and "Naked Objects eh? One > of the silliest ideas i've read in a while. Who needs UX?" and "... a big > fat helping of Naked Objects insanity". This is the usual level of debate > these days (which is to say... it's just not worth having the debate). > > With respect to the DDD list, it ultimately got too depressing to be on > there; any approach not some derivative of CQRS or used a framework was > apparently wrong. ORMs and dependency injection into entities and even ACID > (you know, the highly controversial use of begin tran ... commit) are just > not how things are done over there. A common stance is to trivialise NO as > only being appropriate for CRUD systems. Here's a fairly typical thread > [3]. There was another quite spectacular thread more recently on the same > forum... search for "InfoQ article on Restful Objects" and brace yourself > to be offended. > > And it would seem that even our major existence proof of the validity of > the naked objects pattern (namely, the Irish government system) does not > seem to cut the mustard. I remember highlighting this on the DDD list and > saying that the CIO for the government was on record as saying "'in 30 > years of managing IT projects, I have never been more satisfied". He also > commented here [4] and was quoted more completely here [5]. The DDD list > trashed this quote, as well, though [6]. > > To counterbalance all this doom-and-gloom, Ed Yourdon yesterday tweeted: > "We don't see things as they are, we see them as we are (Anais Nin)". This > cheered me up enormously. > > HTH > Dan > > [1] http://foruse.com/articles/nakedobjects.pdf > [2] http://www.infoq.com/articles/Intro_Restful_Objects > [3] http://tech.groups.yahoo.com/group/domaindrivendesign/message/9525 > [4] http://www.infoq.com/articles/RAD-Naked-Objects#view_37542 > [5] http://nakedobjects.net/news/news_intro.shtml > [6] http://tech.groups.yahoo.com/group/domaindrivendesign/message/9563 > > > > > > > > > > Mark > > > > >
