iTranslated by AI
Understanding MVC Architecture in ThingWorx
Thinking about MVC Architecture in Thingworx
The goal is to understand how the MVC architecture is applied.
MVC Architecture
MVC is one of the software architecture patterns for GUI applications.
Modules that make up the application are classified into Model, View, and Controller.
- Model
Includes modules responsible for business logic, data storage, and integration with other systems.
This is the core part of the system. - View
Includes modules responsible for the GUI display. This part is primarily for presentation to humans. - Controller
Anything that cannot be classified as either Model or View becomes the Controller.
It invokes Models in the appropriate order, dispatches user input to the correct Model, and contains some of the logic for driving the View.
The basic processing flow involves calls from the Controller to the Model.
Actions responding to user input follow this flow.
Calls in the reverse direction, from Model to Controller, are restricted or prohibited.
Additionally, the View is never the target of a direct call.
For other interactions between modules, instead of calling processes directly, notifications are sent to request data retrieval, prompting the other side to ingest the data.
Notifications are sent from the Model to the View or from the Controller to the View, and the View ingests the data according to data conventions.
Because MVC is clear and user-friendly, it has been adopted by various platforms.
Through continuous improvement over time, many derivatives of MVC have emerged.
Some derivatives have been significantly modified and given new names (such as MVVM).
Many interpretations of MVC exist depending on the context. Thingworx's MVC is one of them.
Thingworx's MVC
Thingworx is claimed to be MVC by its developer.
By using ThingWorx, you are taking advantage of the Model-View-Controller (MVC) pattern.
The following text explains how MVC is realized:
You are constructing a logical model of your device, which is independent of its user interface. You can then construct a view using the application builder. Finally, you connect (or bind) the model and the view, which produces the controller logic.
Let's take a look.
Thing
In Thingworx, you can create individual entities called "Things".
You can add Properties to a Thing to hold values, and Services to define processes (using JavaScript, etc.) that return values. Things can be accessed from Mashups (described below) or called via REST.
By using pre-defined Thing templates to create advanced Things, you can also operate arbitrary RDBMSs using SQL.
Items defined within a Thing can serve as the Model.
Widget
Web pages created in Thingworx are called Mashups.
You can place numerous components called Widgets in a Mashup, each adding display or input functionality. There are also Widgets available for utilizing external Web services.
These can be edited in the Mashup Builder.
Widgets can be seen as having both View and Controller characteristics.
Data bindings
Widgets have dedicated Properties used for configuration and data storage.
Widget Properties can interact with each other, allowing values entered in one Widget to be connected to the Property of another Widget.
Data bindings automate notifications of data changes and their ingestion.
You can also associate multiple Things with a Mashup. By connecting a Thing to a Widget, data retrieved from the Thing can be displayed in Mashup components like graphs or grids.
A Service connected to a Widget in a Mashup becomes a Data service.
A characteristic of a Data service is that it possesses "All" and "SelectedRows" Properties. In other words, it provides a row-selection interface regardless of whether the data retrieved from the Service is in a two-dimensional format.
Event bindings
To retrieve data in a Thing's Service, an explicit call is required, and an Event is used for this purpose.
Events occur when specific conditions are met within a Widget. For example, clicking a button triggers a Clicked event.
If an Event and a Service are connected in the Mashup Builder, the Service will be called at the next timing after the Event occurs.
Event bindings can be seen as part of the Controller that connects Widgets and Things.
Conclusion
This concludes the architecture of Thingworx.
Since Thingworx itself is easy to operate, something equivalent to a Controller can be created just by connecting Widgets in the Mashup Builder.
Nevertheless, understanding the architecture will likely lead to better design.
I hope this helps.
Discussion