IDataObject provides an interface used by the standard data-driver implementation in Quino.
While many of the dependent subsystems in Quino assume that data objects inherit from this interface, the data driver itself integrates this interface only in one place, the
IMetaObjectHandler. Instead of assuming that an individual data object supports any operation, the driver asks the handler to perform operations on data objects.
Though the default implementation
GenericObjectHandler assumes an
IDataObject (the GenericObject), a product is free to implement a handler that uses reflection to use pure POCOs. This is not to say that this would be easy, but that the driver makes no assumption to the contrary.
IDataObject is the top of a hierarchy of less-specific and less-powerful interfaces that expose less functionality so that individual components and services in Quino can impose as small a requirement as possible on calling code.
A service can be completely independent of implementation by getting the
IMetaObjectHandler using the
IMetaObjectHandlerResolver, much as the data driver does when it prepares an
IDataCommandContext. This approach is guaranteed to work with any type of backing-object implementation, but requires more work.
Whereas the core services in Quino make this effort, outer layers prefer instead to make some assumptions about the underlying implementation by requiring that objects implement one or more of the following interfaces.
IMetaClassAware: The object knows its own
IMetaObject: The object knows and can manipulate its
Stateand values for properties
IMetaChangeTrackingObject: The object knows and can manipulate its editing state, both overall and for scalar properties
IDataObject: The object knows its
IDataSessionand can get or set related non-scalar data
Service implementations are encouraged to require only the interface with the surface area that is actually used, rather than just using