InetSoft Product Information: Dashboard Design Patterns

Style Intelligence uses advanced object-oriented techniques in its design. Some of the designs may be directly or indirectly exposed to the users as part of the public API. For users familiar with object-oriented design patterns, the use of the patterns is obvious. Since understanding the design patterns is very important to mastering the InetSoft API, we will briefly go through the major patterns in the public API.


The Model-View-Controller (MVC) design pattern is widely used in graphical user interfaces. It provides a well-defined way to separate the presentation, management and storage of data.

By separating the view and the data, a dataset can be stored in one place and be presented by multiple views, possibly in different formats. Because there is only a single copy of the data, it is very efficient in terms of storage, and avoids the need to redistribute and populate data changes during programming.

The MVC design pattern is the primary mechanism for defining a report. The report itself always acts as the view in the MVC pattern.

BI DemoRegister

Models for Reporting

The model used by the report can be derived from a number of sources. The report is a view that presents data retrieved from the screen components. The screen components serve as the data model for the report, in addition to their possible role as views for the actual data source.

InetSoft products provide built-in support for printing screen components to a report, especially in table format. By using adapters, printing a table from the screen is as easy as adding one simple function call.

The other plausible setup when using Style Intelligence is to use the same data source used by the screen components. In this case, the report simply becomes another view of the data.

The data source can be as simple as the model used in the screen component, such as the table model in the Swing JTable. Additionally, the data source can be a distributed source or database. Since this setup requires the report to query the data directly from the data source, it could potentially be less efficient than getting the information directly from the screen components.

If the information required for a report already exists on screen, we recommend using the screen data as the model.