You can extend an MDriven application at the model, ViewModel, integration, generated-code, and rendering levels; this page is for teams deciding where to place a customization.
Choose an extension point
Start with the model when the requirement describes the business domain. Use a ViewModel when the requirement changes how a specific user or system consumes that domain. Add custom code, an integration, or a custom rendering only when the model and ViewModel do not cover the requirement.
| Requirement | Extension approach | Example |
|---|---|---|
| Enforce a business rule | Model rule with OCL (Object Constraint Language) | Define an OCL validation that prevents an invalid value from being accepted. |
| Present domain data for one task | ViewModel | Create a ViewModel that presents the data needed to manage a show without changing the underlying domain model. |
| Provide data and actions to another system | ViewModel exposed as a REST or web-service interface | Use a ViewModel that reads and writes application data and runs actions as the interface for a native mobile application. |
| Connect an external service | REST API integration or an integration implemented with C | Connect the application to an existing system through its API. |
| Add hand-written framework logic | Separate partial-class file in C# | Add application logic in a separate partial class; regenerated code does not overwrite that file. |
| Change generated presentation | Custom template or replacement rendering | Replace a part of the supplied rendering with your own rendering while retaining the model and ViewModel. |
Extend business behavior in the model
Use MDriven Designer to describe classes, associations, constraints, and state changes in the model. The model is the source for generated database structures, code, and application behavior, so model a rule here when it belongs to the domain rather than to one screen or integration.
OCL is the declarative expression language used for queries, derived values, and business rules. For example, use an OCL expression to calculate a derived value dynamically in a ViewModel, or use an OCL validation rule to constrain a domain value.
A state machine describes an object's lifecycle. For example, model the states of a show seat as part of the domain when its state determines what actions are valid.
Shape a task-specific interface with ViewModels
A ViewModel shapes model data for a particular use case without changing the domain model. It can compute derived values with expressions and can read and write application data and run actions.
For example, create one ViewModel for staff who manage shows and another reduced ViewModel for a phone workflow. Both ViewModels can work with the same domain classes while presenting different attributes and navigations.
ViewModels can also define an interface for another system instead of a human-facing view. For example, expose a ViewModel as a REST or web-service interface for a native mobile application that needs to read data, update data, and invoke actions.
Control access to behavior
Use AccessGroups and ViewModel enablement when a customization must control whether users can perform an operation. MDriven analyzes OCL and action expressions to determine whether they can affect persistent data.
For example, set a View-Enable expression to false to allow benign interactions while preventing an expression that would permanently change persistent data. If the automatic determination needs to be overridden, the WillEffectPersistedDataOverrideValue tagged value can be applied to a Column, ContextAction (ViewModelAction), or ClassAction.
See Documentation:AccessGroups, InterestGroups and ViewModel-Enable for the persistence-affecting rules and the per-ViewModel read-only mode.
Integrate external systems
Use REST API integrations to plug external services into an application. MDriven also supports integration implemented with C and APIs for working alongside existing systems.
For example, an application can use an API integration to access data in another system and include that data in its own interface. Keep the application domain in the model and use the integration boundary for the external-system connection.
Add custom C# logic without changing generated files
MDriven Framework generates code as partial classes. Put hand-written C# logic in separate partial-class files so that regeneration does not overwrite it.
For example, when a requirement needs logic that cannot be expressed in the model, add that logic in a separate partial class that extends the generated class. Continue to change the domain structure in the model; MDriven can update the generated code and database while preserving the separate hand-written file.
MDriven Framework also supports templates and code updates for C# and VB.NET.
Customize rendering
Use declarative UI customization for behavior that can be expressed with OCL, such as visibility or styling. Use custom templates when you need to override default rendering, and replace supplied rendering when a different rendering is required.
For example, keep a ViewModel that defines the data and actions for a task, then replace part of its supplied rendering to meet a presentation requirement. This keeps the domain and task-specific data shaping separate from the rendering implementation.