Fulfilling the Promise of MVC

Model-View-Controller (MVC) is probably the most cited example of an architectural software pattern. It was conceived by Trygve Reenskaug working in the SmallTalk group at Xerox Parc in 1978. One motivation for the pattern was the separation of concerns: to allow Model objects to be concerned only with modeling business capabilities, not with how their data and methods were presented to the user, nor with capturing or responding directly to user inputs.[1]

In the last decade, interest in MVC has grown again, but from a different direction: web development. Here, the problem wasn’t having domain objects that knew too much about presentation, but the reverse: too much business logic ending up in the presentation layers, resulting in poorly-structured systems that are hard to maintain. Today, MVC has become a popular pattern for the development of ‘data intensive’ web applications, and is supported by many frameworks including ASP.NET MVC. [2]

Yet though a web application built on MVC is probably better structured than one using prior patterns such as web-forms, most such systems are still nowhere near as clean as the pioneers of MVC envisaged. In a typical MVC application, today, a huge proportion of business logic ends up in the Controllers, and a surprising amount leeches into the Views. And most of the remaining business logic is delegated, by the Controllers, to services. So the Model objects end up as little more than dumb data structures. The pioneers of object-oriented programming must be turning in their graves! (Ole-Johan Dahl and Kristen Nygaard died within six weeks of each other in 2002, just a year after having their contribution recognised by the prestigious ACM Turing Award).[3]

A little over ten years ago, I started to propose an alternative architectural pattern specifically to address this issue. The idea was driven by two principles. That ...

If you went back to the original idea of putting all your business logic as methods on your domain (Model) objects - even if some of those methods delegated on to services - that it ought to be possible to create a complete, rich, object-oriented user interface directly from that model using reflection.

and that ...

If you created your user interface entirely automatically from the domain objects, it would force you to do a better job of the domain modeling. To pick up on the subsequent work of Eric Evans in Domain Driven Design, it would force you to make your model a true representation of the ‘ubiquitous language’ of the business, because there would be no opportunity to paper-over-the-cracks with custom views and controllers.

The theoretical work became my PhD thesis, which also coined the name of the ‘naked objects’ pattern [4]. In the six years since then, a dozen frameworks that claim to implement the pattern have appeared [5]. The only two I can personally vouch for are the open-source ‘Naked Objects for Java’ (currently in the process of being incorporated into the Apache ISIS project), and Naked Objects for .NET, which is now my principal occupation.

Whenever the naked objects pattern is mentioned it seems to divide the audience: people love it or hate it. I have to say that some of the strongest criticism comes from those who’ve neither examined the idea properly, nor tried our framework. They seem to imagine that it must somehow require that UI responsibilities be put into domain objects. It doesn’t.

More legitimate criticism is directed at the idea of a generic user interface. The initial versions of the Naked Objects framework did not permit any customization of the generic auto-generated user interface. To many people this is unacceptable. I would point out that the largest user of the Naked Objects framework (a Department of the Irish Government) has not only found that the non-customizable user interface works perfectly well for their 1500-user mission-critical applications, but that it has given them huge advantages. However, I do accept that the non-customizable user interface is one of the biggest factors that has limited both the applicability and the appeal of the naked objects pattern.

So a year ago I set my team a challenge to ‘square the circle’: could we create a framework that would synthesize the naked objects pattern with the MVC pattern - giving you the full benefits of both, without the downsides of either? We’ve just released the result - called, unsurprisingly, Naked Objects MVC [6]. With this framework you can write a data-intensive web application solely by writing domain objects. (These are POCO domain objects - they don’t need to inherit from the framework nor implement any interfaces.) It uses Microsoft’s Entity Framework to create the underlying persistence layer on relational database, and it uses ASP.NET MVC 2 to create the HTML user interface.

You can then customize the generic user interface as little or as much as you want to.

Now at this point, Naked Objects MVC might sound like a number of other frameworks that can generate a CRUD interface from a data model - Dynamic Data being just one of them. There are some similarities, but two important differences.

First, Naked Objects MVC does not involve any code generation or ‘scaffolding’. I’m not keen on that approach, though I accept that some people like it. With Naked Objects, if your domain model has 100 classes, you don’t end up with 100 (or, more typically, several hundred) views and/or controllers. The entire generic user interface is created using a fixed set of about a dozen generic Views, and a single generic Controller.

Secondly, Naked Objects MVC does not just provide CRUD access. Rather, it reflects the full functional capabilities of the Model objects. If a Model object has a public method then, by default, this method will be made available on the objects ‘action menu’ at the user interface, and if that method takes parameters then these are reflected-on to create the dialog for that action. Adopting the pattern of programming by convention, you can provide methods that will validate the input parameters for that action, hide, or disable the action based upon the object’s state, for example.

Where the generic interface is not suitable, you can customize the user interface at one of three levels.

The first level of customization is using CSS. By editing the CSS files you can not only change the overall layout and design of the application, but also the layout and design of individual object types, properties, actions, or parameters. The reason for this is that in the (dynamically) generated HTML we’ve paid a lot of attention to the use of class and id in our divs. Adding this line to the CSS, for example:

.Property#RetailStore-SalesPerson {color: Green;}

will cause just the Sales Person property on the RetailStore object to be colored green.

By the way, we’re also very committed to generating pure HTML. Even the drop down menus of object and service actions are achieved using CSS. Currently, our only use of Javascript is to add the JQuery pop-up calendar to date fields. This can be removed, or more Javascript added according to your preferences/constraints.

The second level of customization is to write custom Views, which may inherit from one of the generic Views or be built from scratch. Naked Objects MVC provides a large set of HTML helper methods that make it very easy to build new views of objects and actions. For example, you might wish to display a SalesOrderHeader with its collection of associated SalesOrderDetails rendered as a table. Your View, strongly typed on SalesOrderHeader would just need this code:

<%: Html.CollectionAsTable(Model.Details)%>

Or to display a Customer object with one of its actions (CreateNewOrder, say) already open as a dialog on the same page, your view, strongly-typed for Customer, would just need to add this line:

<%: Html.ObjectActionAsDialog(Model, "CreateNewOrder")%>

Alternatively, if you prefer type-safe code over brevity, you can use an overloaded version that takes a lambda, thus:

This will insert into the custom view the HTML for a dialog box for the CreateNewOrder action. It will pick up both the types and names of the parameters for that action (in this case a string and a date), will enforce any mandatory ones (picked up from annotation), and will apply any validation rules by automatically invoking the ValidateCreateNewOrder, if one exists.

(Although Naked Objects MVC framework has a proprietary license, the generic Views and Controller, and all the HTML helper methods, are provided open source [MS-PL] to allow them to be extended or modified.)

The third level of customization applies when you want to customize the flow of the application. Incidentally, one of the biggest surprises when we first implemented the naked objects pattern several years back, was not that we could reflect both object state and behaviour in a generic view, but that we could have a completely generic application flow. But that generic flow is only suitable for situations where a user has the opportunity to learn the (few) generic interaction patterns - typically for internal users. To use the distinction made by usability guru Alan Cooper, this generic application flow is best suited to ‘sovereign applications’ [7]. For ‘transient applications’ (including anything that is public-facing) then a customized flow - typically a highly-scripted one - is just as essential as a customized presentation.

You can achieve this by writing custom controllers, either that operate in isolation or in conjunction with the Naked Objects generic controller. When I find myself having to do this, I am always astonished at how difficult is: trying to keep your Views, Controller methods and routing information all in synch. Not that it’s any harder than writing a native ASP.NET MVC application, it’s just that the generic approach of Naked Objects MVC really spoils you! The good news is that I’ve found that you can avoid much of the need for this just by using a View Model. Let’s say you’re developing a public-facing web application that takes a new travel booking in a tightly-defined six-step process. You can do almost all the work by defining a BookingCapture object - still within the Model the project, but marked up as [NotPersisted] - which captures the data and tracks the status. At the end of the stages a single Confirm method on that object then creates the various objects to be persisted. You might need to write a couple of ultra-simple controller methods, but all the real work would be done in the Model, and the presentation of the six stages of the booking handled by six custom views of the BookingCapture, which are very easy to write.

To be sure, the introduction of this not-persisted BookingCapture domain object is a move away from the pure Naked Objects pattern (where all objects are persisted entities) - but I stress that this is strictly for the situation where you do need a tightly scripted user interface. Whenever we build a substantial new application using Naked Objects, we always start by designing the application for the user who is completely-trained, completely-reliable (makes no errors), and completely trustworthy. Not only can this type of user cope with the fully-generic user interface - but they actually need the freedom that it offers. (I was recently invited to give a talk, in Norway, entitled ‘Treating the User as a Problem-Solver, not a Process-Follower’ [8]). Having done that, it is then comparatively easy to layer on such controls and constraints as are needed by mortal users, and such scripting as is needed for public users with zero prior knowledge. By contrast, most application designers start from the other end, and then find it very difficult to create a more flexible system for the more capable user.

In summary, the overall principle of Naked Objects MVC is that when you create a model you should be able to run that model immediately as a complete application by means of default Views and Controllers. You then add customized Views and/or Controllers, but only where you need them - and preferably as late in the development process as possible, so that you concentrate maximum development effort on the model.

Although, to my knowledge, ours is the first framework to achieve this, it isn’t an original idea. It turns out that this was what Trygve Reenskaug had in mind in the first place, but wasn’t able to implement back in the late ‘70s. The only reason I know this - there’s no published record of it - is because Trygve was the external examiner for my PhD thesis in 2004. He’s retired now - an Emeritus Professor at the University of Oslo - but still as sharp as nails ...

"They seem to imagine that it must somehow require that UI responsibilities be put into domain objects. It doesn’t."

You bet it does. When you add an attribute "Title" to a property in a domain class what do you call that? seriously?

I watched the code first demo and for that very "Hello World" model there were more than 10 references to Naked Objects artifacts, from attributes to the container. I find your use of the term POCO very misleading because, to me, POCO signifies a class that is isolated from the frameworks that are using it which makes it easy to test. POCO is a technique to achieve separation of concerns. So you don't have to inherit or implement interfaces but you're doing the same thing using attributes and methods.

So the principle does not hold, but what about in practice?

Going back to the code first sample, all was achieved is a prototype like UI. I don't think the framework can implement a real world UI that is maintainable on the long run like stackoverflow.com for example.

Finally, I'd say the idea is very nice (write an OO domain model and forget about the rest). But it so good to be true that you have to realize that it is just that, a nice idea.

We get a lot of off-the-cuff reactions like this one [sigh!], as I believe I mentioned, but for the record ...

Yes, there are quite a few Naked Objects attributes in our domain models BUT

1. That number keeps reducing as Microsoft gradually introduces equivalent attributes into System.ComponentModel.DataAnnotations. When we started promoting the idea of attributes to mark up a domain model there were none such from Microsoft. I'm pretty confident that all of our Naked Objects attributes will have been replaced by Microsoft ones within a couple of years. You can of course take the view that the use of any attributes, even Microsoft ones, tie your POCO to an externality - but then the same could be said of the language as a whole.

You can argue that [Title], to pick one example, is a reference to the UI (and the same could be said of any number of System.ComponentModel.DataAnnotations also), but I suggest that it is really just a declaration of intention - it is not a call to a UI. And actually, Title has far more uses than in the UI - it allows generic functionality such as FindByTitle methods in repositories.

2. We supply the source code for all NakedObjects attributes (under MS-PL) - so you are not tying into anything proprietary,

Ditto for the Container - the one point of contact with the framework. This, though is defined as an interface IDomainObjectContainer, with a handful of methods and, again, we provide the source code of that interface under MS-PL. The container is an injected service.

The attributes and the container are defined in a single assembly called NakedObjects.API, which is very small and all open source. That's the only one you need in your Model project. It is only your run project that needs the framework assemblies.

So, yes, it is absolutely possible to make a very simple mock of the container and inject that for testing purposes, in complete isolation from the framework - just as you might choose to mock out any of your other injected services.

You wrote: "Going back to the code first sample, all was achieved is a prototype like UI". It's as though you haven't read the article! Out of the box (the demo was just a few minutes long) you get a generic UI. If that isn't suitable for your purposes you then customise it. That's the whole point!

As for your assertion that this is just a nice idea, I'll remember to pass that on to the Irish government where (as I mentioned to in the article) they have very large scale mission-critical systems built from Naked Objects - using, as it happens, just the generic UI.

1. I doesn't matter of the references are to Microsoft or NakedObject dll. Who cares? so instead writing "using NakeObjects.Api" you write "using System.ComponentModel", is that a goal worthy of achieving? What's the difference seriously? you're missing the point completely, Richard. Please read what I wrote carefully. it's about "Separation of Concerns".

These references are for a purpose different than the domain model (in this case it's the UI). What will happen if add some attributes for UI and some for the database and some (i don't know) for a web service? you'll end up with an EJB. Any by the way, Martin Fowler coined the term POJO (which POCO was later derived from) to get rid of EJB's. So we're back to square one.

2. It doesn't matter if it's open source either. See above.

3. Your framework cannot create a stackoverflow like UI. Period. The reason I mention stackoverflow because it's a typical ASP.NET MVC application with a real world UI that's built on Microsoft stack. If you can mimic one screen of it with NakeObjects then take a look at your domain classes and you'll see my point.

4. The Irish government example is not a objective argument because nobody except you knows about the application and how happy they are. I guess I can go an ask them but I don't speak Irish.

It was (true) separation of concerns that gave rise to the whole idea of Naked Objects.

To suggest that the addition of attributes to a domain model takes you back to EJB is absurd.

The whole point about attributes is that they aren't calls to a framework. When done correctly, they just provide additional information *about the domain model* - it is up to any external framework whether it uses those attributes and/or how. Now, admitedly, attributes can be badly designed and add very little generic value, but when they are well done they just provide generic hints. To give one example, the only reason we still have [Hidden] (a hint that a property is unlikely to be of interest to any user - like a different variant on public/internal/private if you like) is because the Microsoft equivlent is so awful: (ScaffoldColumn(False) I think it is). Generally I am happy that their attributes are generic, but this was a bad one.

I believe that you should mark up the domain model as much as you can *provided that what you are doing is providing information that is still generic to that model*. That's all we are doing. If I add [DefaultValue] or [Required] to a property, say, then that is providing useful model information to other layers.

You are confusing this idea with mark-up that provides information about other layers - for example mark-up that instructs the database what to call the column that maps a property. This sort of thing is rightly criticised. Dan Haywood wrote a good article about this distinction, but I can't put my finger on it right now.

3. "Your framework cannot create a stackoverflow like UI. Period." Yes it could, but Naked Objects isn't really aimed at that type of application, and certainly offers much less advantage there. Naked Objects strength is in data intensive applications - applications that involve dozens, if not hundreds of entity types. These are more commonly internal applications rather than public ones, though they often have a narrow public interface into part of the system. When you try to build one of those applications using the same approach that you would for desiging stackoverflow, say, you just end up with much too much custom UI logic - very slow to build and very hard to maintain (I've seen it, all too often).

4. " The Irish government example is not a objective argument because nobody except you knows about the application and how happy they are". How much research is that assertion based on? One of the minimal pieces of verification is that every RFT that the Department of Social Protection has issued since 2006 for new IT applications (and there have been a good many) explicitly state that it must be built on Naked Objects. This is publicly-accessible information - though generally only read by people who bid to build big systems. BTW it's all in English ;-)

I see that the discussion is turning philosophical which is counter productive. You can argue that these attributes are "about the domain model" and not "for the UI" and I can argue otherwise. It's about interpretation and that's all good. However what matter at the end of the day is how maintainable the whole thing is because that's the idea of all these principles/buzz words. One measure of maintainability is testability. How do you unit test a [Required] or [Default] attribute?

So you say that NakedObjects is for those business applications that don't need fancy UI but only to manipulate data in CRUD manner. Nothing too complex. Something like what LightSwitch or Rails is for. That's all good. But you have to agree that these are not the type of applications that people arguing against the framework are trying to build.

When you say the Irish government people are happy, who do you mean and from which perspective? It could be that managers are happy because they have applications that "work" and they don't care how many hours developers cry in front of their monitors.

You don't unit test a [Required] attribute (other than, if you really want to, testing that it is there on an object/property/method, which you can do easily enough through system reflection) because it *isn't* providing any functionality - it is just a label. You might well be using your domain model within a framework or other application that made no use of this attribute. However, if you were using that model within a UI that claimed it *was* recognising and interpreting that attribute then you would certainly need to test that UI to ensure that it was, say, forcing the user enter a value. This we do all the time. We provide our own test framework that can test these things generically, but you are certainly not bound to it and can use whatever test harness you like.

"NakedObjects is for those business applications that don't need fancy UI...". I'm happy with the first part this sentence. If you want a highly-designed UI, and your domain model is relatively low complexity application then don't use Naked Objects.

" ... only to manipulate data in CRUD manner. Nothing too complex." But the second half od the sentence is completely wrong - and a serious mis-quote of what I actually said. Where Naked Objects really scores over either Lightswitch or Rails is when you are dealing with large, complex domain models. Fundamentally, Naked Objects is about getting back to real OO, and real OO was all about scaleability for complexity - that was the great insight of Alan Kay and the SmallTalk team. That's why it is so annoying when people dismiss it as a simplistic prototyping tool - the opposite is true. (I made this point on the Hanselminutes interview which you might like to listen to.)

In regard to the Irish Government you seem to have prejudicially determined that they can't possibly be happy with our approach in some important way - without actually knowing anything about it. I'll leave you to do your own research on that one. FYI, the organisation I am referring to the Department of Social Protection, though in the 10 years that I have worked with them they have changed their name at least four times! This hints at what the biggest issue was: business agility (which includes maintainability but other things also). The Naked Objects approach has proved its worth on that benefit alone.

So it's not testable but you insist it's a POCO? Then let's agree to disagree. I forgot to ask you why do you think EJBs are bad?

"Fundamentally, Naked Objects is about getting back to real OO"

My view of real OO is let the domain model do what it does and render unto the UI the things which are UI’s. But again let's agree to disagree.

"you seem to have prejudicially determined that they can't possibly be happy with our approach in some important way"

I didn't say I'm not happy with your approach. I said these are not POCOs. That's all. Plus i think it's has a lot of limitations, but every framework does. I like for example the use of conventions and the generation of boilerplate code at runtime. I think this is a fantastic idea. But i think the use of attributes is a poor choice. I rather like bridge these concerns with the UI through specialized objects using a DSL. Something similar to how Fluent Nhibernate bridges POCOs to the database. That will make everything testable and you'll have separation of concerns and "real" POCOs.

If your biggest truck is with the idea of putting annotations on domain objects: we do have convention-based methods that are equivalent to most of these. For example, instead of adding a [DefaultValue(1)] attribute to an int Quantity property, you can write a method 'int DefaultQuantity()' instead and Naked Objects will pick this up. I personally only resort to a Default method if the determination of the default is dynamic - I prefer the terseness of the attribute. You will probably prefer the method approach because it is more conventionally testable. But I would point out that you are still going to have to test that the UI is actually making use of that method anyway. I probably have a slightly different view to you about the role of unit testing in relation to other forms of automated testing (we typically use several different levels of automated testing), but am happy to differ on that one.

(I can't say for sure that we have method equivalents to all the attributes - that certainly was true at one point, but may not be 100% now, I'd need to check - but it's certainly many of them).

There are different opinions about what is and what is not allowed in a POCO (or POJO for that matter). I accept that for some people that means no attributes; others find them perfectly acceptable within the definition. I'm happy to agree to differ on that one.

My only intent in stating that the DSP had changed their name four times was in case you did decide to research it further - I was just trying to warn you that you won't find a lot of references to 'Department of Social Protection' - because it is a very recent name. A name change isn't in itself very significant but in the case of government, it does oftern reflect a massive change in boundaries and responsibilities which have profound systems consequences. But the manjority of change are nothing to do with the name changes.

We definitely could do everything by convention rather than annotation (as I said, we once did) - that we don't now is simply because we have chosen not to: we like annotation. If you believe that all use of annotation is intrusive then Naked Objects is just not for you.

The comment about 'all the other references to the NakedObjects.API' is a red herring - the only other reference is to the IDomainObjectContainer as already mentioned. What we have advised others who have an issue with this is simply this: move it all behind your own injected services such as factories and repositories. It is really quite easy, if you are so motivated, to get to there being just one single reference to IDomainObjectContainer in the entire model. What most people don't seem to realise is that in a typical conventional system they have hundreds of equivalent connections. For example, any system that uses Microsoft's EF typically has many reference to the DbContext in their domain code. The Naked Objects IDomainObjectContainer hides all that completely. The fact that most people put all these connections into their Controllers rather than Models and claiming that they have real separation of concerns is, I believe, poor thinking.

"Back to the government example, I don't know what happened there and I don't really want to but you got to brag about something other than the government to prove you're good, No?" You seem to be implying that if it is a government example then it doesn't really count - or is at least necessarily inferior to a private sector one. I find that quite distasteful. Possibly it is just 'bait'. But either way I think I'll bow out at this point.

What about the "Object Lifecycle" and Created, Persisted, Updating, OnUpdatingError, etc.. etc. This looks very much like the old ASP.NET page lifecycle, don't you think? and leakage of the persistence into the domain model is obvious. I bet it doesn't end here because the problem is fundamental to the framework.

" or is at least necessarily inferior to a private sector one. I find that quite distasteful."

As organizations, governments, are inferior to their private sector counterparts. This a fact and not an opinion.

Hi Duraid Duraid,I've worked for a while with this framework and would like to add a few comments based on my experience.I first want to mention that for a few months I had a similar reaction to the one you seem to have. In fact, I notice most of the developers in my team went through the same process.So the first disagreement I had was that, while it Naked Objects is obviously a true MVC implementation, there was code that seemed to deal with the Viewer side of the pattern.

Let's take the Title as an example. This recognized method rendered as the object's window's title, giving your domain object a feeling of uniqueness (although titles are not necessarily strict identifiers). So there e I was, writing viewer code in my entity class. Sometime later, we started to use the Command Line Interface Viewer. The same code was reused without further change. The title I had written was as useful as with the GUI Viewer. Then we used Fitnesse as a Naked Object client. Same thing, the title was as testable as any other part of the entity. We then started to design the title as carefully as the entity itself: the Title was a crucial part of the entity itself; it played a role in the domain. Is the way you perceive an entity regardless the viewer. The same applies to element like disabling an action or property, etc. They are domain concepts really, take a look at techniques such as Design By Contract for example, it says testing of preconditions is a responsibility of the client code. When you write a Disable<myAction> in Naked Objects you are indeed writing a pre-condition to a domain action. Do you think you are just writing code for disabling a button/menu option? Then you are confusing cause with effect. It is a domain concept to prevent an action to execute based on unsatisfied pre-conditions. It is Naked Objects task to render this domain concept accordingly. My point is: take out all the code you think is “Embedded Viewer” code from your class. You will find yourself adding that code to your viewer in a different (and less generic) way. That’s OK in fact, but what if you want the domain entity to reuse that validation? Well, you need to factor it out of your viewer. A “validation” object? Well, then you didn’t gain much, you just separated behaviour from data, an anti-pattern in Domain Driven Design (and in proper OOP in my opinion).Finally, if you remove this code from your entity, then you need to bind this logic to the related action or property. This mapping will probably exist in some XML configuration or similar mechanism. I did this in a research project, and while it seemed good and flexible at a start, it didn’t add much benefit in the end. I came to favour convention over configuration as a means to adopt truly Agile development. If you really keep your code clean and do your code refactoring frequently, you will soon be annoyed by all your metadata spread in files and databases to this end.If this is not an issue for you, then I bet you are not paying your design debt, which will cause much more headaches than adding a few attributes to your code.Regards,Sebastian</myaction>

Thank you Sebastian. I was looking to read some firsthand experience. I see your point that some of these attributes although they seem they belong to the view have a true domain meaning, like the Title you mentioned and maybe Default, StringLength and others. Also, it makes very much sense that separating these behaviors into a separate entity doesn't pay much and maybe is an anti-pattern.

However I have a couple of concerns. First what if different clients need a slightly different behavior? for example what if an attribute should be hidden for one client but not for the other?

Second, the object lifecycle worries me a lot because I know that behaviors that are a little complex tend to split among multiple event handlers, for example between created(), updated() and OnError(). This, in my view, hurts maintainability a lot. Also, it's not unit testable because there is so much magic happening at the framework level that you can't mock.

So yes, having behaviors in one place (the entity) can be beneficial as you mentioned but i see a downside for it too.

>> First what if different clients need a slightly different behavior? for example what if an attribute should be hidden for one client but not for the other?

Both Naked Objects MVC and also Apache Isis use an authorization mechanism for this, based on roles. This acts at two levels: hiding (of properties/collections/actions) or just disabling them (read-only/greyed out). The implementation is as a decorator, which means that we can add on authorization concerns late on.

Not really sure what your concern is here, your objections all sound a little FUDdy. It is worth stating that the framework takes the view that entities know *that* they are persisted, but they don't know *how* they are persisted.

The [required],[optional] and other attributes make the software more testable. The optional & required logic is completely DRY, it is handled in one place the can be thoroughly tested rather than being scattered among many individual parts of the presentation layer.

Hi Duraid,I worked four years in the project that Richard mentioned and I would like to provide some feedback:

Richard is correct, the client (managers) and users consider the application a huge success. The project is now running for 7 years and is fulfilling the original project expectations where the new solution has been capable of consolidating a large set of legacy and heterogenous systems into a single solution in an iterative manner; it has also provided a high maintainable application that can be enhanced in a inexpensive manner as a result of the solution’s auto-regression testability capabilities.

In terms of testability, the framework was designed having testability always in mind, making possible the adoption of RAD and TDD methodologies. The framework provides its own testing framework that leverages the creation of tests against the business domain entities. This is the only project where I have seen possible for the System Test to automate their test cases using a customised Fitnesse client which demonstrated to be a huge success among the test team and the client.

Here is what you need to consider before attempting to question the topic presented by this article.Do you want to waste your time on programming UI and because of that ask for more time to complete the project? You need to realize that 'Naked Objects' free you from this dumb work and allow you to concentrate on the business logic.Yeh, you can complain that the UI will be 'unusual', but as with any other tool or application you need to get accostomed to it. Recall how the web browsers were criticized when they showed up. But they did survive all this buzz.As to the Richard Pawson's statement that 'Naked Objects' fulfills the MVC promise. This can be questioned. The reason for that is that both ASP.Net MVC as well as Swing do not implement true MVC (as it was originally suggested by Trygve Reenskaug). Even in Smalltalk-80 the idea of MVC was modified from the original one to what better suited the needs. In ASP.Net MVC it is not MVC, but MVP, just because it is difficult to separate V and C and those are tied into the presentation layer.Regards,David

I have to admit that I am a huge fan of the ideas behind NakedObjects. We have to a very large extend conceptually adapted the NakedObjects framework, however, we allow UI customization which we think also happens in NakedObjects. Putting annotations like “MemberOrder” on properties is designing the UI.

Apart from any technical discussion, the main benefit is the real sense behind “Domain Driven Design”: to establish the use of the same language among developers and business users. In fact, I can give various examples of business people expressing problems where I can directly pinpoint to the code just from listing to what they say. This is a result of objects and their behavior being a direct representation on the UI.

However, I also have a criticism, or more a suspicion: The article and its topic MVC has actually very little to do with the idea of NakedObjects (as I see it). I suspect that it’s just been used to catch the attention of audience. Hence, the article seems to be more motivated by marketing your product. It should lead people thinking: if you want to have real ASP.NET MVC then use NaketObjects.

I see your point, but my main objection was at the use of the term POCO. This term is used often in the framework description I believe for marketing rather than technical reasons.

I argue that since the entities rely so much on the Naked Objects framework ecosystem that they're not plain old CLR objects anymore. They could well be a Plain Old Naked Objects.. a PONO or maybe...PORNO?

The point is not how you call things or terms used, but the major shift in the paradigm - there is no need to program things that you can use without programming. Personally, I am following this paradigm for over three decades and greatly appreciate the efforts of Richard Pawson and his group with their attempt to promote this idea to much wider audience.Another comment is related to the testability mentioned several times. You do not test IDE, compilers, or any other tools and frameworks you use in your development. You rely on the vendor. The same is with the 'Naked Objects'. You get it from the shelf as any other product available on the market. You need to test just what you write. Nothing more than that. So, there should not be any problem with testability.

I agree with you that you only have to test your code, no question about that. But what if the framework makes it hard or impossible to test your code? That's why the analogy of EJB was brought up because it's hard to test and that's why POCO or POJO were created. As an example of the Naked Objects framework I mentioned the object life cycle which i think can be problematic for testing. For example what if the behavior falls into the created and the updated events?

> over three decades

Wow that's like the stone age in computer programming time. Who are you Alan Kay?

@Duraid Duraid1. -If your definition of POCO means no references to anything at all, than it seems that you could claim that Naked Objects MVC is not POCO by your definition.But I am surprised that no one mentioned that you are not obliged to use attributes within your domain layer to be able to use Naked Objects MVC. All you need to do is to put these attributes and references into your presentation model (view model) classes within your presentation layer. You may inherit your view/presentation model classes from domain classes, or map them via automapper, or have a completely different structure for your view model than your domain model - it is all up to you. So Naked Objects has all rights to claim that it is POCO.

Nevertheless creating a separate view model may lead to some additional work, which may be not practical in some (rare) cases.

From a practical architecture point of view, there is a big difference between IO/persistence type of references, domain/application specific references, layer specific references and references to a common infrastructure with no IO/persistence and application/domain not specific, like a reference to attributes and interfaces in Naked Objects MVC. It is architecturally perfectly fine to reference this kind of common infrastructure, and there is typically no harm in doing that, no violation of any design principles. Who cares if you can claim it is still POCO or not? Will you not use LINQ within your domain layer just because it is a reference to System.Linq? Would such a kind of POCO be useful and practical for anybody?

I agree though, that some attributes of Naked Objects MVC can belong to a presentation or persistence layer, provided you have to change parameters of such attributes for presentation or persistence reasons, and not for domain specific reasons. I am not an expert in Naked Object MVC to tell if it has these sort of attributes. If it does, I would suggest to provide an option to use fluent configuration style of configuration, rather than attributes withing Naked Objects MVC framework. Even though fluent configuration may be less practical for some people and projects, for others it can be a good selling point, because fluent configuration can be easily moved to an appropriate layer and allows to avoid re-deployment and re-testing of domain layer logic when all you change is a presentation layout. As soon as Naked Objects MVC is an open source project now, anyone is free and welcome to make this kind of improvement.