Chapter 2. Approach of a Data Instance
Introduction
Most applications, if not all, are about data transformations. Therefore, "good" data management strategy greatly influence "good" design of the overall application.
The following sections identify weaknesses of current designs. Then, the section "Proposed approach of DataInstance" reveals the proposal of a solution which addresses all described weaknesses, but first of all, certain terminology is defined for clearer understanding of the following text.
Terminology definitions
Figure 2.1 shows a class diagram representing hereby defined entities and their relationships. The figure is frequently referred to in the following text.
Figure 2.1: Class Diagram: Defined entities and their relationships
Business entity: is a "real world" entity, as it exists, such as somebody's personal information record, a mail message, a schedule event, etc.
Model: provides certain amount of information about "business entity". The provided information varies according to purpose of modeling the "business entity".
Model realization (MR): there is a lot of ways a model can be realized by: a painters picture, a technical drawings, a wooden replica, computerized model, etc. Obviously, the "computerized model" is the one of our interest. More granulate differentiation of "model realizations" are described by the following terms.
Business object (BO): is an object dedicated for computer realization (representation) of a "model" of a "business entity". There is two kinds of "business object": generic and specialized one.
Specialized business object: explicitly holds properties of the model. It is realized by dedicated class having properties and behavior tailored for the given model. The examples of such a class are: Person, Message, Event. Advantages of this kind of business object is (1) the easy of use because the information (model description) is hold by the class definition and (2) it supports typed design --- the class (such as "Person") is of a model specific type rather then generic one. However, the typed design strategies are difficult for generic purpose components.
Generic business object: is reusable for all kinds of business entities without introducing (coding) new extra classes. It is also suitable for designing / cooperating with generic purpose components. There are several implementations of the "generic business object", one of them is proposed "DataInstance", described later on.
Implementation dependent model realization (IDMR): is a "Model realization" which is *somehow* dependent on its implementation nature. This includes components which are part of the development environment (JavaTM: Bean, File, Stream; MSVC: Component, ActiveX; ...) or results from used technique/technology (JDBC: ResultSet; JSDK: HttpServletRequest; XML: DOMNode, SAXDocumentHandler; etc).
Discrete IDMR: is just finer classification of "Implementation dependent model realization". It includes MRs which are realized by set of entities. It is, for example, a set of variables where each of them is holding one model's property value. The most used (in this text) example is set of HTTP parameters. Each HTTP parameter holds a value entered in WWW form. Assume that there is a WWW form used for editing a person's record. When user enters the form's field values (edits the person's record) and submits the form to the server, then the field data (representing a "ModelRealization" where "Model" is the person's record) are accessible on the server as HTTP parameters. Therefore the HTTP parameters are classified as "Discrete IDMR".