Jean-Paul Boodhoo (is that a great name or what?) wrote a post recently title Screen Bound DTO’s. I thought it was interesting from the standpoint that where I work we do something very similar, and it’s always neat to read about other people who congregate toward similar designs.

I suspect, judging from Jean-Paul’s post, that what we’re doing is similar (but in fact it may not be).

The first difference I can see is that we don’t call our objects DTO’s; they’re just DataTables. To me, a DTO represents some sort of data that will be transferred over the wire. Our screen bound objects do not travel the wire, they just get created for UI purposes only.

Our domain objects come in only a couple of flavors: single entity objects (like Employee), custom collections (EmployeeCollection) and managers (which roughly translate to UnitOfWork objects which manage an aggregation of objects for a use case). Many times we need to display data to the user in a customized way, because that is what customers do: they ask for the same set of data to be displayed a myriad of ways. Instead of writing several different versions of the same objects or collections, or writing different DTO’s to send over the wire for specific requests, we prefer to keep to one business object for a give set of data. This makes our service layer a little simpler since there is only one type of Employee object in the domain, for instance. If you want to know what the HireDate is for an Employee, there’s not five different ways to get at that data, just one.

So how to display that data (almost always collections) in unique ways? We opt for DataTables and then write mappers that perform the translation at the UI level. The mappers are GUI classes; the domain model doesn’t know about them or care. Services have no idea they exist. Only the GUI layer knows about them.

A typical scenario for us is to query for a collection of business objects and then display that collection in a specific way. The Presenter class in an MVP triad will then pass that collection off to a mapper, which will map it to a DataTable. The DataTable then gets sent to the view, which binds it to a grid for display.

When the user wants to delete an item from the grid, the View delegates that call to the Presenter which then removes the item from the actual business object collection. The DataTable then gets updated via the mapper which has an Update() method. The Update method allows us to only create the DataTable one time and bind it one time. This has a neat feature; it allows us to detect changes to a set of data visually, so we can do things like bold or italicize changed fields in the DataTable via change events.

If the user wants to add a new item, they do so via a Dialog or Wizard (depending on the complexity of the business object) and then the object gets added to the business collection. Again, the DataTable is updated via the Update() method and the UI gets updated as well. In this way the DataGridView is never used to perform adds or deletes; just the domain objects are used (and thus any validation or other business logic can be performed as required).

As Jean-Paul says, this sort of design really helps when you’re doing development from the top down (or as he puts it, Top Down Development, but do we really need another xDD acronym?). From our perspective, we really like doing development this way. It makes sense to our users because they interact with the UI and don’t often understand business objects, despite the data they work with on a daily basis. We find it easier to conceptualize a problem if we can capture it from the user’s perspective in terms of a view or multiple views. As the problems get solved the domain objects fall out of the UI solutions, and as customization of the data is required the mappers get created on an as-needed basis. All of this lends itself very well to a test driven approach as you can unit test the presenters and mappers very easily. There’s a really great feeling that comes when you finally fire up the application for the first time in several hours of coding and the whole thing works and the data gets displayed correctly, yet you haven’t looked at the UI outside of the IDE.

The neat part is that the domain objects remain unaffected by any of this. They’re evolution can vary independent of the mappers. Other views can use the same domain objects and map them differently if they need.

Ayende poses the question: How do you sell maintainability? Evan adds his $.02 to the discussion.

I’m going to open by saying you don’t sell maintainability. Selling is about getting people to buy what they already want, and Stakeholders don’t want maintainability. What they want is a finished product. And therein lies the rub.

Stakeholders don’t understand maintainability because to them, software is like buying a car. They expect a finished product. They expect a finite amount of work and a finished good. But that sort of mentality doesn’t mesh with the reality of software development.

It is unfortunate that software came into the industrial age so late in the game. People have been conditioned to expect a finished product. But software is soft: it can be changed, updated, improved and fixed. Unlike a child car seat, for instance, which has to be recalled when a flaw is discovered, a software program can be patched with code that fixes the problem. Unlike a Barcalounger, which cannot be upgraded with cup holders, a software program can be improved with new features without you having to replace the old version.

Software that is worth keeping and using is worth maintaining. But how do you convince a stakeholder to invest in maintainability? I don’t think you do. I think you have to start somewhere else. You have to start with something they already want.

Stakeholders want software that does exactly what they wish of it. They also want software that can adapt to changing requirements. These are things that you can sell. Maintainability then becomes a requirement to make the other things reality; it becomes something you don’t have to sell.

To get them sold on the things they already want, I think the first thing you have to do is convince them to invest in the concept of software as a living entity, like a garden. You have to engage them in a paradigm shift. You have to get them to understand that software that does what they want will never be “finished”; it will continue to grow and mature; it will never be “done”. Sure, it will have an initial period of development that looks an awful lot like landscape construction, but that is just one phase of a much longer lifespan; a lifespan that can go on for as long as the software is deemed useful.

Software has the advantage of being soft. This becomes part of the selling strategy. If the stakeholder wants the software to (a) do what they wish and (b) be adaptable to changes, then the malleability of software becomes a key feature. It is this malleability that you must use to force the paradigm shift; to get them to understand that software is not like building a bridge, or skyscraper, or car. Software is not like purchasing a yacht, it is like growing (and maintaining) a beautiful garden.

Once the stakeholders understand that software development is not finite, but a long term commitment, then they will understand what it takes to make it successful: people. People are necessary to grow the garden, and people are necessary to maintain it. And that is when you can enforce maintainability. Because by then you should have sold them on the things they already wanted. Maintainability then becomes a requirement, not an option. And you don’t have to sell requirements; those things are mandatory.

As for .NET and RAD-like tools: I don’t think stakeholders can understand or appreciate the differences until the paradigm shift happens. Until they see software as a living entity that requires maintenance, they will never appreciate the difference between maintainable code and flashy RAD prototypes. As long as software is like buying a car to them, then the RAD applications will continue to impress. So from my point of view, this is about educating the stakeholders.