Turn off that LightSwitch, and Let's Get Naked!

So, no sooner had I blogged about VS Lightswitch (I mean literally the next morning) I discover that there is a whole architectural pattern out there that tackles the problem that I have been considering developing a framework for  - Naked Objects. The shame of my arrogance (mixed with some naivety I concede) to think that I may be the first out there to strive for, well not so much a Silver Bullet, but well, just something better for such architectural commonality.

Richard Pawson coined the term Naked Objects when he had the vision of exposing domain objects to the UI (OOUI).  Naked Objects was the result of his Ph.D. thesis, written a few years ago when I was still trying to get to grips with proper OOAD/P and .NET 1.1.

The same curiousity that got me intrigued by VS LightSwitch had me interested in Naked Objects, that is a sound belief in DDD; the presentation, data (service and whatever other) layers are simply scaffolding for the domain. Get the domain correct, your app from a business representation perspective will be correct. As a software engineer that is the most difficult thing to get correct, and is the thing that is most likely to make or break the success of your project/app.
 
UI Designers of course argue different, arguing that a good UI is critical and fundamental to a successful application (it is this stick that Larry Constantine beat the Naked Objects concept with some time back.
I am not entirely unsympathetic to their stance and I certainly think a good UI helps, but without a sound domain model a fancy UI is worthless.  The same cannot be argued for the reverse (I know since I've developed a few such apps, a good few of which were deemed a success and are still in operation today).

Interestingly, Pawson has recounted how Trygve Reenskaug himself had stated that the Naked Objects pattern was the ultimate end game to his Model-View-Controller pattern.  This certainly gives weight and validity to Naked Objects as an architectural pattern (in the West of Scotland we call this "hawners").

Of course Pawson has went on to develop his own framework for his Naked Objects pattern, namely Naked Objects and more specifically Naked Objects MVC for .NET, utilising the ASP.NET MVC 2.0 technology.  The Naked Objects MVC framework is interesting from a number of points of view:

• The Naked Objects framework is solely centered on domain objects as indeed Pawson claims. In other words, there is no code needed from you the developer, for the presentation layer or the data layer, leaving you to concentrate on getting your domain model correct.  If Naked Objects and VS LightSwitch were ever in direct competition, in my opinion, Naked Objects would win for this reason alone. Even although the Entity Framework (EF) Code-First CTP was released before VS LightSwitch beta, VS LightSwitch is still driven from the data model, suggesting that the intended user demographic of VS LightSwitch is pre-dominently people with no proper OO experience.  Naked Objects on the other hand is clearly a product for OO developers.
• The domain objects are also true POCOs, meaning that you can port your domain model to another framework or to your own custom framework/application at a later date if you decide the output of Naked Objects is not to your liking without any rework to your domain.
  
• The Data Layer of Naked Objects is build on the Code-First component of EF, which doesn't require any data modelling or data access code, you hook up your domain model and away you go.
• The Presentation Layer uses reflection to obtain not just the state, but also the behaviour of your domain objects in order to display the functionality on offer in your UI.  This means that there is only actually a few generic views and controllers needed in the framework in order to render this behaviour and state at run time.
• The Naked Objects MVC product also allows you to customise your views, meaning the end result doesn't have to be a set of similar looking views obviously generated from boiler plates. Indeed, you can add on your own views to extend and customise your UI further if necessary.  (My guess is that this is Pawson's reply to Constantine's criticism's of generated, standard, no-design UIs.)

However, there are a couple of concerns I have about Naked Objects MVC at first glance:

• The UI uses terminology such as "Create Instance", which is great for technical people, but it means business users need to learn a new set of terminology to use your application.  To me, this seems to contradict the Ubiquitous Language so keenly advocated by DDD.
• The use of reflection for all domain objects in order to build dynamic pages at runtime does concern me a little with regard to performance. Depending on the complexity of your objects and/or intended UI page there is a possibility that you may end up with a performance problem in your web application. (I am willing to be set on this one if I have it wrong.)
  
• The data layer is built on a CTP of EF.  Admittedly, CTP4 does seem to have made major advances for the reputation of the EF as an ORM, but I know my boss isn't interested in running production applications against CTPs any time soon.
• Pawson also claims that you have flexibility in your application by allowing you to customise your Views not just by stylesheets, but by use of a raft of very helpful HTML helper classes as part of the Naked Objects framework.  He also makes a case for ultimate flexibility as the framework allows you to use your own custom Views and with every likelihood your own Controllers also.  Personally, I'm not convinced by this as a selling point of Naked Objects MVC because if you take away the Views and Controllers you have cranked yourself, for all intents and purposes you are left with the domain model you also created and the EF CTP.
  

As a final observation Pawson claims that Naked Objects works well for sovereign applications but it does not lend itself very well to transient applications.  Personally, I don't think that application posture is as applicable today as it once was; today's end users don't just use software as a job tool, but as a medium that is part of their day-to-day social interaction. As a result, their expectations are higher and sub-consciously or otherwise, the expectation (no matter if they use it 7 hours per day or just in passing) is not just on how it looks, or what functionality it offers but how it actually behaves (usability).  If the UI generated by the framework is rigid in structure and not intuitive to users, this could limit the adoption of Naked Objects frameworks such as Naked Objects MVC.

My previous observation of having a sound domain model and not necessarily having a good UI should be qualified by the times in which this software was written.Going back to touch on Constantine's point about the UI being vital; end users these days are not expecting a good UI as apposed to a good functionally sound domain implementation, or even vice versa - they want both.

ID the Identity

Since I stared working in my new place I've come across the same sort of design issues that I encountered in my previous company.  This is a post originally from my previous blog.  I wanted to highlight this issue again since it has reappeared in my conscious but I also wanted to take the opportunity to update it with new learnings, so I moved it here.

One such common design issue is the matter of object identity and how it is used within the application under development.  What I have seen all too often is the following:

The Primary Key reference from the database record is the object identifier!

So, hands up who recognises what is stated above because they have done it in the past, are currently supporting a legacy app with this nuance, or are still doing it?   So, as eveyone heard all too often as a teenager "everyones doing it, whats the problem?"

Well for a start I've tried not to use the term "problem" up until now because, well for one I'm just not the dramatic Graham Norton type, and two I'm sure if you are doing this on your current development project it probably won't have manifested itself as a problem.  Maybe not yet at any rate. 
But consider these..

By exposing your primary keys as application IDs, you are writing this identifier in stone.  Of course your identifier should be immutable, but  this cannot always be guaranteed with the database sequences that are used for primary keys.  Or, for many successful (and therefore large) systems, the database has to be scaled up into server farms so GUIDs are recommended to guarantee uniqueness even across multiple database servers.  Who fancies having to remember a GUID for an object identifier?

The reason above is looking at this issue from a purely technical view point.  The rest of the reasons below consider the functional aspects of such an implementation and (in my book) are all the more convincing for it.

Consider this - database primary keys are quite simply a database storage mechanism.  They are a handy way to uniquely identify individual records in relational databases.  Relational databases in enterprise applications are for persistence and nothing more.  Why let your persistence mechanism bleed into your functionality?  The primary key value is not application data and therefore should not feature in the application.  So, on all projects I have a say on, I now vehemently insist on making the primary key ID a private or protected variable.  For anyone who hasn't previously worked on a project with me, they usually look confused or think I'm making a big deal out of nothing at this stage.

Still not convinced?  OK what about this - by exposing the primary key of the record you are unnecessarily exposing your application implementation to your users.  This may not be a big deal to all developers and all situations, but to customers who want their applications to be as secure as possible, can you truthfully say that you have mitigated every possible security risk when you are advertising database IDs?

Not only have you unnecessarily introduced a potential security risk, you may be unintentionally misleading your customers.  Listening to an old DotNetRocks podcast another reason why this is not a good idea was highlighted - your customers can be misled as to the meaningof the identifier.  The example given in the podcast (thanks Richard & Carl) was that the customer was upset that they had their own customers identified in their system using the database primary key.  When their biggest customer was ID 372 it was a disaster and insisted it had to be changed.  No matter how arbitary that ID is to a developer, perception is everything in business.

And finally for the reason that has me so cantankerous on this subject - in Eric Evans' DDD book he explains

"it is common for identity to be significant outside a particular software system"

What Evans encourages with Domain Driven Design is to let the "domain drive your design".  Nothing insightful there, and it sounds quite simple right? So why isn't this fact enforced in so many software designs? What Evans failed to push home is that when you do have a significant identity outside the software system, the significant identity should be used as the object identifier.  By designing your object model to incorporate such identities you are not only accurately aligning your implementation closer to the business domain, but you are gaining and sharing a better understanding of the business domain with anyone else using this object model (however subtle it may be).  Simply taking the easy way out by using a database primary key is not only encouraging a lazy solution, but is discouraging your development team to realise a better and more accurate design.

Of course Evans goes on to explain that although this is indeed common, identities are sometimes only important in the system context (exceptions to every rule of course).  And that is ok and should be expected also. The main point I am trying to emphasise is that you should always look at the domain to identify an identity for your object.  When there isn't a logical one in the real world, well of course you should have a unique identifier mechanism. Absolutely, but please just do not make it a database primary key!