Data Persistence & Management in Extended MVC Architectures

Data Management Function in Extended MVC

The Data Management (DM) component provides the basic infrastructure for the storage and retrieval of objects within a system. Its primary purpose is to isolate the impacts of underlying data management technologies on the overall software architecture.

Specifying Data Management: Common Approaches

The most direct approach for this persistence layer is to provide a shadow class within the Data Management (DM) component for each persistent class in the other architectural components, such as the Problem Domain (PD) components. The standard DAO (Data Access Object) pattern is widely used for this task.

Essential Features for Data Management Construction

Three important features for constructing the Data Management (DM) component include:

• Creating a shadow class for each class in the problem domain component.
• Allowing shadow classes to be part of a hierarchy.
• Ensuring each object has an OID (Object ID) that maps to a database record.
• Achieving independence from the underlying persistence mechanism.

Shadow Classes in Data Management: Role & Responsibility

A shadow class is a class that abstracts the problem domain (PD) classes responsible for data persistence. It reflects these classes but includes methods for accessing specific databases. This class is responsible for shadowing, saving, and retrieving data in a database or other persistence mechanism. In general, each class existing in the Problem Domain (PD) has its corresponding shadow in the Data Management (DM) component. This class can inherit from a BaseShadowClass, which provides common features such as connection data information, access to the physical environment, and routines for assembling commands.

Object Identifiers in Data Management: Why They Matter

During the conversion process of Data Management (DM) classes to an Entity-Relationship (ER) diagram, each persisted object will have a corresponding record in the database. To ensure a one-to-one (1:1) mapping for this relationship, the object must possess a unique Object ID (OID), guaranteeing consistency during persistence in the DBMS. If, during the conversion of DM model classes to the ER diagram, an object lacks an identifier field, it must be created as a primary key.