Following up on my XML is not a Deserialized Object Graph post, I was thinking about entity classes from RUP. The official definition (from the RUP manual) for entity classes is: “An entity class is used to model information that is long-lived and often persistent” – i.e. stuff we’re going to stick in the database, XML files, etc. In weblog terms, entities are posts, comments, trackbacks, etc. In my experience, these entity classes have little business logic – mostly validation code. The code that will act on this entity are encapsulated within control classes. Control classes are tightly related to use cases. Typically, a one-to-one relationship between use case and control class is a good first order approximation. Again, in weblog terms, the “create post” use case would be implemented as a control class that takes an entity class instance and writes it to the persistent store (database, XML file, etc)
If the vast majority of business logic goes into control classes while the entity classes are primarily data containers, why can’t we just go all the way and make our entity classes conform to the XML Infoset? Expose them via XmlReader/Writer or XPathNavigator (and some as yet undefined interface XPathUpdatable). This way we’ll have parity between the entity classes local to our application and the XML messages we send and receive as we interact with other web services. XML serialization attempts to do this by unifying everything as strongly typed objects. But I’d rather unify around infoset, since that’s what’s going to be consistent across platforms, vendors and technologies, rather than typing systems.