Fulfilling the Promise of MVC

First, regarding this line:

"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.

Richard

You miss the point, Richard.

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.

"How do you unit test a [Required] or [Default] attribute?"

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.

"they have changed their name at least four times!"

How does that say anything!? really?

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.

Not only annotations/attributes but all the other references to the NakeObjectsApi and System.ComponentModel. The whole thing is very intrusive.

I'm ok with using method names, I think it's a very good idea, but I'm skeptical that you can keep all the functionality that way without a major change to the NakedObjects framework.

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?

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.

Richard

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.

>> Second, the object lifecycle worries me a lot ... hurts maintainability a lot.

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.

Dan Haywood
Apache Isis

I don't know about FUDdy but not being unit testable is valid concern, don't you think?

Not being unit testable would be a valid concern. What did you find that you couldn't unit test?

The object lifecycle.

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.

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

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.

> 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?

Thought some that commented here would be interested to know that NakedObjects MVC has gone fully open source.
www.nakedobjects.net/news/news_intro.shtml
nakedobjects.codeplex.com/

@Duraid Duraid
1. -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.

Or am I missing something?

Great Article


Online MVC Training
Online MVC Training from India

The alternative architectural pattern is really interesting.


Online MVC Training