Songhay Design or Just Buzzword Soup? …the Input Data Object
Coming out of the J2EE Java camp we have the business object (the fat one), the data access object (the classic one) and the data transfer object (the skinny one). The revolt against J2EE (which produced Spring and, I think, Hibernate) brings us the term object-relational mapping famously.
None of these terms recognize the existence of a central problem of my life as a developer: the reception of external input and transforming it into native types. What Java people and Microsoft people do is expect their external data to be auto-magically transformed into natives. In my Microsoft world, we have the ‘gift’ of Server Controls (and the proxy stub for Web Services). Until the arrival of ASP.NET MVC (and JSON), my rejection of this wonderful gift from Microsoft has been met largely with suspicion and flippant disrespect. So instead of getting too angry at this, I’m going to look at the term ‘input data object’—knowing full well that someone thought of this before me but has a famous name for it I have yet to discover.
What I am calling the input data object is an object that has one responsibility: take external input and transform it into data defined by a contract. This ‘contract’ is, of course, an interface. So the presence of my input data object implies that there must a backing data transfer interface (data transfer contract). That I would actually bother to define these interfaces means that I have finally discovered that the Extract Interface command can be used to generate interfaces from classes generated by LINQ.
Now some random points:
- I am using the term ‘input’ when the term ‘message’ might be appropriate. However, input looks to me like the superset containing the message.
- The success of implementing the input data object concept is that all code concerned with external input is centralized. The backing data transfer interface represents the results of the work of the input data object—these results are passed to other classes, decoupled from how this work is done.
- My use of data transfer interfaces suggests the design by contract approach (Contract-First development). I am certain that my approach here is underpowered.
- This rather historical article is interesting: “Data Access Object (DAO) versus Object Relational Mapping (ORM)”
- “Business objects are sometimes called domain objects… A business object often encapsulates all of the data and business behavior associated with the entity that it represents.” Rocky Lhotka’s CSLA Framework is the king of making such Swiss Army knives possible.
- This idea comes to me from looking at the source code for a CodePlex.com project called KiGG.