The following transcript is from a 2010 podcast titled “Inside the Naked Objects Framework with Richard Pawson” , hosted by Scott Hanselman.
They go back in time to explore Domain Modelling, Object-Oriented Programming, “Naked Objects”, Domain Driven Design, and Rapid Prototyping.
(Permission to publish the transcript granted by Scott Hanselman in Feb 2025)
“From Hanselminutes.com. It’s ‘Hansel Minutes’, a weekly discussion with web developer and technologist, Scott Hanselman. This is Lawrence Ryan announcing show number two thirty three, recorded live Thursday, 09/16/2010. Support for Hansel minutes is provided by Telerik RAD Controls, the most comprehensive suite of components for Windows forms and ASP.NET web applications online at www.telerik.com. In this episode, Scott talks with Richard Pawson about ‘Naked Objects’.“
SH: Hi. This is Scott Hanselman, and this is another episode of Hansel Minutes. Today, we’re chatting with Richard Pawson about Naked Objects. How are you, sir?
RP: I’m good. Thanks for having me on the show, Scott.
SH: Thank you. I appreciate the time zone and all the trouble as you are on the other side of the pond. So Naked Objects, this is a very provocative name. What, what is that, and should I be worried?
RP: Well, occasionally, it does cause some problems with emails and filters and the like. But, no. It’s a sound idea.
The underlying philosophy is really just that when you develop an application, the only thing you should have to develop are domain objects – the Naked Domain Objects – and you should get everything else for free. The persistence layer should be for free. The user interface should be for free (or at least the default user interface). That’s the philosophy.
SH: That in itself is rather provocative: the idea that the domain object is so important -or so rich – that it would have enough information to generate a user interface is surprising to me. Does this work for any kind of user interface, or only the most basic user interface?
RP: Well, yes. I mean, to contrast this with, say, you know, there are loads of frameworks out there that will take domain objects and represent them as in in a simple data interface, with CRUD methods for updating them and creating and so forth.
But what we do is reflect all of the behaviour of a domain object: all of its public methods become actions that the user can perform or, by default, they become actions the user can perform on the user interface. Unusually in the software industry, I don’t believe that this is the solution to all known problems, but it is very, very good for a whole class of applications, that have quite complex domain models, what you might traditionally call data intensive applications.
RP: It’s not suitable for extremely rich, multimedia style of applications. It’s for, you know, structured data style of applications – it’s good for that.
SH: Alright. Well, so let’s do this. Let’s back up and start at the beginning. How did you develop this?
RP: Well, Naked Objects is an idea goes back more than ten years. It was actually my PhD thesis. And its origin was trying to understand why the power of object orientation, which I was introduced to in the in the late eighties, didn’t really take off in mainstream commercial systems development. And one of my conclusions was that it was, by the time you developed all the layers above and below your domain objects, You lost all the advantages of doing a good job of domain modelling in the middle.
And, there was a lot of work going on even then on how to create a persistence layer automatically from a domain model, and that’s now modern ORMs and Entity Framework in the in the .NET world. But there wasn’t much going on what you could do above the domain model. And I had this just idea really that that if you did your domain model properly, if you made your objects rich enough, it ought to be possible to create an object oriented user interface from that automatically. Now the first ones we did were very much a rich style of client server, user interface. And it worked very well, but you couldn’t you couldn’t modify the user interface.
You had to stick with the generic one that that Naked Objects gave you. Much more recently in fact, very recently, we’ve now created a new version of Naked Objects called Naked Objects MVC that works with ASP.NET MVC, and that gives you a complete MVC application for free, having written your domain objects. And you can then go on and customize the UI to your heart’s content, much as you could for any ASP.NET MVC application. Although, the more you customize it, the more you’ll lose the advantages of it being Naked Objects. So the concept isn’t specific to MVC.
SH: I could do this I mean, really in any in any world. Right? I could do this in WinForms.
RP: Absolutely. In fact, the biggest systems we’ve built have been with a WPF user interface, that was no customizable. It was it was just a direct reflection of the domain model. And I should say that Naked Objects is actually a pattern. It’s an architectural pattern.
And the framework that that my company develops is only one of several frameworks that do implement this pattern now. So I’m using the word Naked Objects in two senses there.
SH: Is Naked Objects a name that you came up with? Because you said that there are other companies. So is your thesis and a company that you run and then others have taken that that thesis, like REST?
RP: Yes. Absolutely. Naked Objects is the name I came up with. It was the name of my thesis, surprisingly enough, in an academic, environment, and people often ask me where the idea came from. And there’s an official story and a true story.
The official story is that it comes from that wonderful quote from Anton de Saint Exupery where he said:
“The design is completed not when there is anything more to add, but when there is nothing more to take away”.
The true story is that there’s a there’s a TV chef in The UK. I think he’s known in the US, Jamie Oliver, who’s called “The Naked Chef”. And I was watching his program one night about ten years ago, and he was talking about, you know, the essence of good cooking is just having good ingredients, and those ingredients should show through in the end dish. And I thought “Well, that’s what I’m talking about!”
You know, the essence of good systems development is just having a good domain model, and that domain model should show right through and be the user experience as well. That’s quite a contrast between the, the apocryphal story and the actual story.
SH: Well, that’s often the way, isn’t it? Okay. So the advantage of this is that you can get a lot of, a lot of code quickly. You can get a lot of you can rapidly prototype, presumably.
RP: Yes. There are some videos on our website, and you can you can see me do a complete system very, very quickly. And it and it’s very tempting to focus on that, the rapid application development aspect. But I think that’s actually secondary.
I think it’s a kind of by-product almost, the fact that you can do extraordinarily quick prototyping. That wasn’t our real focus. The real focus was that if you do it this way, what you end up with is a much cleaner, more agile, more maintainable system. Partly because you got much less code, but also because, it forces you to do a good job of the object model itself. I like to say that Naked Objects “makes good modelling easier, and bad modelling obvious” because if you’re exposing your object model to the users, you’ve got to get it right.
SH: Okay. When applied to ASP.NET MVC, though, you don’t necessarily have to write any Views or Controllers because there’s enough richness in your in your Naked Object model that that you have a controller of your own that’s actually doing the underlying work. Right?
RP: That’s absolutely correct. You don’t need to write a single View or Controller. You just write the domain objects and run it with our generic controller, as it’s called, and about half a dozen generic views that we have.
And I should stress this isn’t code generation. We’re not generating scaffolding pages for the domain model. It’s all done using reflection, and at run-time. The framework is reflecting on the properties and methods of a domain object and then rendering that through this generic controller and views, to give you a basic user interface. And, actually, that user interface is perfectly good enough for a lot of internal use applications.
It’s not at all suitable for a public facing application, where you do need a much higher degree of design and, and a more scripted style of interaction.
SH: So thinking about this in the context of the of the listener who is probably familiar with ASP.NET Dynamic Data, and has probably seen demos where someone would make a Product’s model and a Category’s model and then a UI pops out the other side. And then they are told that it’s not code0generation, then I would immediately (in trying to apply this to what I already know), I would say this sounds like ASP.NET Dynamic Data.
RP: Yes. Although, there are two quite distinct differences:
I mean, certainly superficially, in the first five minutes of the demo, you’d think, yes, there was a similarity. I think the big difference is we don’t end up with scaffold pages. But the bigger one is that, whereas Dynamic Data is about exposing CRUD methods (Create, Read, Update, and Delete), I don’t think there’s any other framework that takes the view of exposing the behaviour of the objects: the public methods as actions. And I think the whole idea of Naked Objects, there were two kind of “a-has!” in it:
The first was “Why don’t we expose the behaviour as well?”
And the second, almost bigger surprise was that if you did that, there was no need to have any kind of master script on top that actually: you just expose the objects and services, to the user, and, that would be enough.
SH: Okay. So these models: what do these look like? Are they more intelligent, or are they annotated? You know, are they filled with .NET attributes and metadata that gives you extra information about them?
RP: Yes. There are two things that you do. First of all, let’s be clear: they are POCOs, that, you’re not allowed to change any class in our framework or implement any interface. There are two things that you do.
1) As you said, is you add attributes. And when we started this a few years ago, that was not a very popular idea, and we had to define lots of our own attributes. Gradually, as Microsoft has kind of got this way of thinking and using it quite a lot, as the attributes have appeared in, what is it, system dot component model dot data annotations, we’ve obsoleted ours in favour of the standard, system ones. So that applies both to specifying things like string lengths, and whether a a property is mandatory or not. And if you want to rename it – if you don’t want to use the default – you can use display name and so forth.
2) And then the second thing we have, which is more unusual, is Programming By Convention. So, if you have an action, let’s say, you know, CreateNewOrder, you can write a bunch of methods called, for example, ValidateCreateNewOrder or HideCreateNewOrder or DisableCreateNewOrder, and those are recognized by convention and picked up at run time, and used to control your access to that method. So Validate will validate the parameters on the action, and Disable will make it unavailable based on the state of the object, for example. So those are the two things you’re doing, adding attributes and using conventions.
SH: Simply by their existence?
RP: Simply by their existence. You don’t need to hook them up in any way. There’s no configuration involved.
SH: Interesting. So it’s all convention based on naming.
RP: Very much so. And this is why it’s a very, very nice match. It’s almost the flip side of Entity Framework Code First, which I’m a big fan of, and I know you did a show about that, recently. So, you know, I like to say that that Entity Framework Code First (in its most recent incarnation), the whole ethos there is you should write POCOs and, you should get the persistence layer for free without having to think about it. And that follows: conventions first, attributes second, configuration third.
And that’s the same philosophy that we have using the same POCOs: creating the user interface following conventions, attributes, and only as a last resort – any kind of configuration.
[advert for Telerik JustMock]
SH: Thanks a lot. With kind of going back in my own personal software development timeline, this seems more like the rich C++ objects that I wrote twenty years ago.
SH: It seems like lately the objects that I’ve been writing have been basically just structs. I mean I say `public class foo` but it ultimately is a pretty stupid object I’ve been passing around, effectively data transfer objects, and you’re basically saying that we should have a lot richer functionality in our in our object, certainly more than the average .NET programmer is used to having.
RP: That’s absolutely right. And it’s interesting that you made the comment there, that, like you used to write, lot of people who – when they encounter Naked Objects (I get emails like this all the time) where people say “You know, it’s not so much that this is new. It’s just that this feels like what I what was in my head twenty years ago when I first learned SmallTalk”. A very common statement I get.
It is going back to that idea, the origins of Object-Orientation, that say that an object isn’t just a collection of properties and associations. It is a behaviourally rich model of a real world thing. And as you say, a lot of people sort of lost that, in the mid-nineties, and went back to go doing dumb objects. And I think that has quite profound consequences. I mean, ASP.NET MVC – the official line, as I understand it, is that the model is where you put the behaviour.
And yet, I mean, I was talking with Phil Hack and Dave Eber about this, recently in in Redmond. The fact is if you look at many ASP.NET MVC implementations, most of the business logic is in the Controllers, and a quite surprising amount has leached up into the Views themselves. And the problem with that is because it works, but it becomes less maintainable once you get some complexity in the model. I think one of the frustrations we have is that, if I do a little demo and I knock up, you know, three classes and so on and so forth, I can make it work and make it work very quickly. But people say “well, I don’t see the advantage”. But where you would really see the advantage is if you were developing, you know, 300-500 classes, in your application.
That’s when you lose the agility, when the business logic starts leaching out into other layers.
SH: So these objects, they are they are POCOs. They don’t have any dependencies on interfaces or base classes of yours?
RP: Correct. There so, with the exception of following a few conventions for those, additional methods (the complementary methods we call we call them), there’s nothing that ties your domain model to Naked Objects, which is quite fortunate.
RP: I mean, when we were trying to get this idea off the ground several years ago, obviously, people were very, very reluctant to try something that new and that radical. And the but the one saving grace we could say was “Well, look: if you develop your domain model using Naked Objects, even if you decide down the line that you just can’t cope with, you know, this style of user interface or, you know, some other problem, you could still take the domain model and write a conventional, application, whether it was in MVC or in WinForms, on top of it.” You wouldn’t have done anything unusual to the domain objects to get there.
SH: Now what about persistence? How do what does what does Naked Object say about getting these things into a from an object model into a relational database?
RP: We rely a 100% on Entity Framework. We did some early experiments with Hibernate, or rather nHibernate. Well, at the time that we were trying it, it wasn’t really rich enough. I think it’s obviously moved on a long way now, and Naked Objects could be made to work with that.
But we decided to, kind of go with the Microsoft flow, and go with Entity Framework. We were obviously extremely disappointed when Entity Framework 1 came out, as a lot of people were. But Entity Framework 4 works really well for us, and you can use that Model-first or Database-first, or, increasingly, Code-first. I mean, Code-first is not officially released. It’s still experimental, but it does work very, very well with Naked Objects.
SH: This is really interesting. So then what are some of the objections? I mean, I could see someone saying that that “We’re going against separation of concerns” because so much, emphasis is being put on having really smart models.
RP: Yes. I hear that one quite often. It’s a little frustrating because, I think that Naked Objects separates the concerns better than anything else does. I mean, there is no user interface logic in the model. And, you know, whereas in most other approaches, you end up with business logic leaching out into the other layers.
Whereas we say “actually, you’ve gotta keep them separate” because the generic user interface doesn’t know anything about the model or vice versa. So I don’t think that’s really a valid objection, although people do seem to imagine that what we’re doing is putting user interface logic into the into the model.
You know, the most we’re doing is adding attributes, and they’re increasingly standard, system attributes anyway. A lot of people say “well, I can see this would work on the small scale, you know, for a simple demo, but I can’t see it working on a large scale.” And that also is frustrating because, really, the opposite is true.
I mean, we we’ve built systems that involve hundreds of domain classes, and hundreds of users. And, actually, the benefits are much, much clearer on a large and complex model than they are on a simple demo, which you could have knocked up in Microsoft Access or, what’s it, “Lightship” or one of those technologies.
SH: Haha, “Lightswitch”.
RP: “Lightswitch.” Sorry.
SH: Although I think “Lightship” is actually a funnier name. We should change that. We should start calling it “Visual Studio Lightship”.
RP: Well, if you haven’t got your “Unicorn Edition of Code-First”.
SH: Yeah. The “Entity Framework Magic Unicorn Edition”. Well, that’s not any more controversial than “Naked Objects”, frankly.
RP: Although I have a theory about why you called it “Unicorn” in the “Magic Unicorn Edition”, which is – I don’t know if you’re a fan of “Blade Runner”, but in the director’s cut of “Blade Runner”, Ridley Scott supposedly got Deckard to dream about a unicorn, and that was meant to be a hint that he was in fact a replicant.
SH: Exactly.
SH: Suspicious about that one. Very astute of you.
Okay. So we’ve got no code generation, and you can do more than just CRUD. You’ve got convention-over-configuration when it comes to your unit. There’s conventionally named methods and properties, there’s attributes. What if I want a UI that’s extremely custom, though? What if I don’t want a basic looking application? I want something very fancy.
RP: Well, there’s nothing to stop you writing a completely custom MVC application. You can write as many custom views and custom controllers as you want, on top of the domain objects, in using standard MVC patterns. I mean, we provide a whole lot of HTML helper methods that help you make the calls into the Naked Object model – but you can do that.
Obviously, you’re going to lose the advantage, but, I mean, all applications are going to involve some amount of that. In fact, I’d like to draw a distinction that I think isn’t drawn nearly enough in the software development world:
You know, the user interface guru, Alan Cooper, who wrote “The Inmates Are Running The Asylum”? He drew the distinction between Sovereign Applications and Transient Applications, where Sovereign Applications were largely internal applications that users use all day, every day. And Transient Applications are, for example, public facing applications.
Now it seems to me that most of the focus in software development in the last few years has been on Transient Applications on very high touch, very high design. You know, designed to be used by people who’ve never seen it before and maybe never gonna see it again. All the kind of stuff you see at Mixx, for example, and it’s all great stuff. And that is a requirement for those sort of applications.
But that’s not the way to design Sovereign Applications. Not only is it too expensive to design Sovereign Applications that way, but, actually, in a Sovereign Application, you necessarily got a lot more complexity, and you want to be able to give the user (who’s been through a learning curve – they are an employee of the company) typically you want to give them much more control. You know, the ability to do things in an order that suits them, not just to follow a small set of scripts.
And not much attention has been paid to that. And Naked Objects, although you can use Naked Objects to build public facing transient applications, the benefit is less clear there. Where it’s really good is in these internal, data-intensive complex-model type applications.
SH: Have you found anything that doesn’t work? Have you found situations or models or domains in which Naked Objects falls down?
RP: Well, it as I say, it’s not so good for a highly scripted, high touch multimedia style, you know, Silverlight style, public application. Beyond that, I would say and it’s not good for unstructured data. I mean, it is a relational-database kind of world that we operate in. That’s its strong point.
SH: This might be a difficult question: Why do you think this isn’t more popular?
RP: Well, I don’t think it’s the name! I think the name ought to add to its popularity. I think it’s quite challenging, and you alluded yourself earlier to the fact that, you know, a lot of people have, either ceased, to put behaviour on objects – or even consciously believe that’s not a good idea. I’m not sure why.
I think we didn’t help ourselves to some extent with the earlier versions of Naked Objects, where the resulting user interface was not customizable. Now as it happens, our biggest customer, which is the Irish government, that’s the version of Naked Objects that they use. And they they’ve said to us that they don’t want to go into customizing the UI. They’ve gained such huge benefit, ironically, from being able to say to the users “No. You can’t customize the UI. Now focus on what it is that you want. Focus on the domain model.”
And what’s interesting there, is that if you go and talk to the users, and these are government Clerical Officers: they all talk the same language. You know Eric Evans, in “Domain Driven Design” talked about the Ubiquitous Language that, you needed a model that represented the ubiquitous language of the business. Well, that’s what they’ve got there.
And the developers talk, in that particular case, in terms of “Customer” and “Payment” and “Scheme” and “Case”, and “Officer”: that’s what the user sees on the screen. The user talks about “Customers” and “Cases” and “Schemes” and “Payments” and “Officers”. And so the user can translate their requirements very, very easily. The user will say “Look, I want another action on the customer object so that I can say, ‘Show me the most recent Payments made to that Customer’.”
And you now don’t have all this translation process of what that means for the developers. The developers understand immediately that means a new action on that object – a new method on that object.
SH: So I asked a couple of questions on Twitter about this in preparation for the, interview. I could only assume that you have Twitter searches as well, so you may have followed some of the discussions. There was a couple of interesting questions and comments and one of them I thought was interesting from, Scott Bellaware who basically said that exposing raw domain objects out to kind of any external user agent is kind of getting away with something.
SH: You’re filling it with abstractions that are giving it hints on how to make the UI. Is it really a domain object, or is it really some custom thing? I mean, we realize that it’s POCO. It’s technically POCO, but how…
RP: Well, you know, that’s a valid question. But I mentioned the Irish government earlier, and I can pick an example there:
The first big application that we did for them, there were something like 300 domain classes – 300 Naked Object classes, if you like – in the model. Now of those, … if you actually went in and looked at the .NET classes (they actually wrote it in VB.NET, but it could equally have been in C#), if you looked at the .NET classes and you showed them to a business user, the business user would recognize more than 90% of those. There are very few objects that would do it that that are doing something that the user doesn’t recognize.
And secondly, more than 90% of those correspond directly to persisted entities. So there I think there were there were a very small number. In the first system, there were about three domain objects that you might call today View Models, meaning they were constructions purely to facilitate something on the user interface. They weren’t persisted, but that’s three out of 300 in that particular case.
SH: Okay. So that from your perspective, it is really about modelling the business domain and I think that was a very interesting – you said that a huge number of those objects were quickly recognizable. Like, the language that they were speaking wasn’t MVC or .NET. It was the language of the business.
RP: Absolutely. And, you know, I’m a great believer in Domain Driven Design.
And when we conduct the analysis sessions and, obviously, we prototype rapidly and we show them feedback, but you’re all the time, you’re listening out. When the users are talking, you’re listening for nouns that they’re using that aren’t in the model. So a good example is in this Irish government application: they pay pensions. In Ireland, a lot of people pick up their pension at the local Post Office through a “Payment Book” (that’s now gone electronic). So, obviously, we had Payment book as an object, and that contained Payments.
But when we were talking to them, I heard them refer a number of times to the “book renewal cycle”, meaning “Once a year, De La Rue prints all these books”. And we started asking the question “Well, they’re using this noun: ‘book renewal cycle’. Why isn’t that in there in the object model?” And as we probed on that, we decided it should be that there is now a persisted object. Each Payment Book is associated with its Book Renewal Cycle.
SH: Who was your external reviewer on your PhD thesis?
RP: Well, it was actually the Norwegian professor, Trigvik Reinskauch, and he is not terribly widely known. Except that he was the inventor of the MVC pattern back in 1978. And it wasn’t my decision that – you know, it’s never your decision who your external examiner is – and, when it became known to me that that’s who it was gonna be, I was a little nervous because a lot of people, were saying, well, this “Naked Objects” pattern flies in the face of – or contradicts – the MVC pattern, because where are your Views and Controllers? Now I didn’t feel that was true.
Our view is that, I mean, Naked Objects is MVC. It’s just that to begin with, your Views and Controllers are completely generic. You’re writing the models. And, I walked into my, viva (as they call it here), or defense as it would be called in the in the States, when I finished my thesis. And there he was, sitting there with the other examiners, and he said “Well, I’d like to put you at ease, Richard. We’re awarding your PhD straight off, without any further questions except for our own interest.”
And what he then went on to say, I thought it was really interesting. He said “When I read this, I realized that this was our intent back in the late seventies when we were working on NBC. The intent was that when you had a model, you ought to get a generic view and controller for free, so that you didn’t have to write anything. And you should only then write views and controllers as you need to deviate from that generic presentation.”
But he said “We never did it”. It was never done back then. And, so, you know, here I was, whatever that is, 25 years later, actually doing it.
SH: Well, I really appreciate you taking the time to sit down, and explain this to us. And where can – unless you want people going around and googling with Bing for “naked” and “objects” – where’s the best place for people to learn about this pattern and to start playing with it themselves?
RP: Well, incidentally, if you do Google or Bing for “Naked Objects”, you’ll be surprised that the first 500 hits are to do with us. The next 5,000,000 would be what you might expect. But, no: go to www.nakedobjects.net, and, that’s where we describe it all. You anyone can download the free evaluation version of Naked Objects MVC.
Right now, it’s the evaluation version is the whole thing. You can develop a complete application as an example application with it. You just can only run it locally if you want to deploy it. You need a licensed version. But there’s also a bunch of videos on that, site, makingobjects.net, and, that’ll give you the idea as well.
SH: Well, brilliant. Well, thanks a lot. You’ve given us a lot to think about, and we’ll all go off and do the reading and decide for ourselves.
RP: Thank you, Scott.
SH: Thank you, Richard Pawson, and this has been another episode of Hansel Minutes. I’ll see you again next week.