[Admin: This content comes from the original mobile-friendly PDF.]
Introducing UX: What about the existing framework?
At this point, you might be asking: “How does the existing TRIRIGA framework deal with MVC today?” The short answer is “not too bad”.
For the model, we already cover this MVC component to a certain degree with our business objects in Data Modeler. The business objects, along with their fields and relationships to other business objects, do a pretty good job of modeling real-world entities and their relationships. But business objects aren’t flexible enough by themselves. Ideally, the model could contain additional data sources like queries and integration data.
Next, for the view, we cover this component moderately well with our forms and queries. But they aren’t so great when we’re dealing with (1) usability, (2) page-rendering performance, and (3) responsive design. So untying these restrictions on visual interactions or user experience is a key goal. Later, we’ll dig deeper into what these restrictions are.
Finally, for the controller, we already cover this component really well with our workflows and state families. To be clear, our workflows can fit into both the model and controller. Either way, our workflows do a good job of representing the business rules, while our state families do a nice job of establishing the data lifecycles. So no problems there.
But here’s the thing. Although our existing framework applies a partial MVC pattern that’s “not too bad”, the main problem is in its separation of responsibilities. Or lack thereof, as we’ll see next.