You can use low-code and no-code development in MDriven to define an information system in a model and deliver applications without manually maintaining each implementation layer.
Low-code and no-code in MDriven
Low-code and no-code describe development approaches where you configure a system from a high-level model rather than write the database, server, API, and user-interface code for every feature.
In MDriven, the shared definition is a UML information model created in MDriven Designer. The model defines concepts such as classes, attributes, relations, rules, and workflows. MDriven uses that definition to provide the corresponding application layers.
For example, an employee directory can have an Employee class with Name, DateOfJoining, and Photo attributes, plus a relation from Employee to Department. Instead of separately defining those values in SQL, a Web API transport class, API controllers, and front-end forms, you define them in the model.
| Approach | What you define | Example |
|---|---|---|
| No-code | Data, user interface, rules, and workflows through model and visual configuration. | Create the Employee and Department classes, generate forms, and configure an action to show a department.
|
| Low-code | The same model-based definition, with code where a specific integration or behavior requires it. | Expose a ViewModel as a REST endpoint and extend an integration with custom C#. |
The boundary is practical rather than absolute. A solution can be no-code for its core business workflow and low-code for a specialized external integration.
Define the system once
Traditional development often repeats the same business concept across several layers: database tables and scripts, server-side classes, API data-transfer objects, controllers, and front-end code. Each layer must remain consistent when the concept changes.
With MDriven, the model is the maintained description of the system. A change to the model drives the database structure, runtime representation, user interface definitions, and available API surface.
For example, if a company now owns many departments, add a Company class and its relation to Department in MDriven Designer. You then update the relevant generated or configured forms rather than manually revise every database, backend, and front-end representation of the new relationship.
This does not prevent analysis mistakes. You can still model the wrong business requirement. It reduces implementation mistakes caused by manually repeating a known requirement in several technical layers.
Build user interfaces with ViewModels
A ViewModel is a declarative definition of data and interaction for a user interface. It determines what the user sees and what actions are available, without requiring you to hand-write a separate page for each basic interaction.
For example, a department seeker can list departments and expose a Show Department action. Configure the action to open the department ViewModel as a modal dialog when the user must remain on the list page while editing a department.
You can also change the generated layout: move fields, add fields, remove fields, and replace automatically created forms as the application requires. Auto-generated forms provide a starting point; they do not restrict the user-interface design.
Add rules and automation
Put business rules in the model so that they remain visible with the data and workflow they govern. OCL defines expressions and constraints, while EAL defines executable actions and flow control.
For example, use an OCL constraint to express that an employee must have a department before a workflow can continue. Use EAL in an action to update related objects or start a defined workflow.
MDriven also supports scheduled actions, email triggers, data exchanges, and REST integration from the model. When an integration requires behavior outside the model definition, extend it with custom C# rather than duplicating the whole application architecture.
Run and evolve the application
MDriven Turnkey runs model-driven web applications, and MDrivenServer hosts model-based server functionality. MDriven can synchronize SQL schemas, render responsive web user interfaces, and expose REST endpoints from the model.
When requirements change, evolve the model and then verify the affected behavior. For example, after adding Company to the department structure, check that users can create a company, connect departments to it, and see the relation in the relevant ViewModels.
Do not treat model changes as exempt from review or testing. The model is executable and is also the long-lived documentation of the business definition. Review it with the people responsible for the business process.
When to use low-code or no-code
Use this approach when your system has business data, relationships, workflows, rules, forms, APIs, or integrations that must evolve over time. The model keeps these definitions together and reduces the number of separately maintained technical artifacts.
A low-code approach is appropriate when you need to connect an existing technology stack or third-party API, or when a requirement calls for custom C#. A no-code approach is appropriate when the required behavior can be expressed through the model, ViewModels, rules, and configured workflows.
Watch the Traditional vs MDriven NoCode walkthrough for an example that compares the repeated layers of a traditionally coded employee application with a model-driven implementation.