|
4.1 How to Model the Application Data Structures Data structures are used within the application as well as being persisted to the database, and it is normally convenient to use different (use-case-specific) aggregations to those used as table structures. These aggregations are modeled as 'dataviews' containing a number of fields (called 'dataview fields' when the context is not clear), and are used both to model data structures for manipulation and data structures as they appear on the screen. As well as a data structure object (sometimes called a value object or a transfer object), the modeled dataview causes a dataview object to be generated. These dataview objects are the centre of the generated aspects of the application. At the back end they connect to entities and directly to databases, they are called by session objects to provide data services and to each other to create the functionality for even higher levels of data aggregation. You may find yourself modeling dataviews for a number of different reasons. Let's start at the front end and work backwards. A screen of information is modeled by a page and that page can have various data fields on it for displaying and collection information. A standard page displays boilerplate text around the top and bottom, menus at the top and the sides and modeled data in the middle. That data is modeled in a dataview. The fields of the dataview correspond both to the items displayed on the screen and to the data entered into the application from it. The second aspect of a dataview you might want to model is to bring together the data to be passed into a business method in a service. If a business method takes a couple of parameters, you can model these directly, but if you need to pass in twenty items, this are best done using a single value object, which is modeled using a dataview. The final aspect is using the persistence services, the linking of data to the database. This is achieved through modeling links from the dataview to the entities. A dataview can be crafted to fulfil a number of these functions, so not all fields in a particular dataview need be used in any one way. Some fields may not appear on the screen and some may, some may not link back to the database and some may. Simple data manipulation is available to the modeler; more complex data manipulation is often best left to an application programmer. If you find it difficult to reconcile the format of the data displayed on or coming in from a page and that which you have retrieved or want to store, you can provide hooks and the application programmer will link it for you. Dataview relations have similar aspects. On the screen, if the page is backed by a dataview, fields on the dataview on the other side of a relation may also be displayed on the page. The value object of the dataview will be enhanced by containing the value objects of all to-one related dataviews, and a list of value objects of all to-many related dataviews. That way a tree of related data can be built up and manipulated. Unless you switch it off, a maintenance dataview will be produced for all entities giving a simple one to one mapping between attributes and dataview fields. This is what is used by the standard data maintenance pages. A modeled dataview can also be used to create a suite of maintenance pages and this can give a slightly different view of the data to the administrators who maintain it. Business functions will normally be fully modeled. Top Tips:
Links:
Copyright © 2001-2006 New Technology / enterprise Ltd. | |||||||||||||||||||||
