You can extend an MDriven solution with model rules, ViewModels, generated-code extensions, integrations, templates, persistence mapping, and model plugins; this page is for developers choosing where a customization belongs.
Choose an extensibility option
Keep the system gist—the business knowledge of the system—in the model. Use an extension point that matches the change instead of moving model behavior into a delivery-specific implementation.
| If you need to... | Use | Example |
|---|---|---|
| Enforce or calculate a business rule | OCL in the model | Define a rule that requires a House to have a related street before a state transition can proceed. |
| Shape data and actions for one use case | A ViewModel | Create a phone-oriented view that exposes fewer attributes and navigations than the corresponding domain class. |
| Add hand-written .NET behavior to generated domain code | Generated partial classes and separate hand-written files | Add C# logic to a partial class without placing it in generated code, so model generation does not overwrite the hand-written file. |
| Connect another system | REST API integration or a ViewModel exposed as a REST or web-service interface | Define a ViewModel that reads and writes system data and runs actions for a native mobile application or another system. |
| Change generated UI output | Declarative UI settings, custom templates, or a view override | Use OCL to control whether an element is visible, or replace a provided rendering for a specific view. |
| Use a database engine not covered by an existing mapper | A custom PersistenceMapper | Implement a mapper for an additional database provider while retaining the model-derived schema and mapping information. |
| Extend modeling behavior | A declarative model plugin or a model plugin with code | Add model-level extension behavior when the required change belongs in the modeling environment rather than in one application use case. |
Put business behavior in the model
Use OCL (Object Constraint Language) for declarative queries, calculated values, validation, and UI behavior. OCL keeps the rule close to the model element it concerns.
For example, a state-transition guard can require a House to have a street relation before it moves from planning to construction. When the model changes, MDriven can identify type-related side effects in expressions.
Use model actions when the behavior changes persistent data. MDriven analyzes action expressions for operations such as Create, Delete, assignments, and collection changes to determine whether an expression affects persistent data.
Use ViewModels for use-case-specific extensions
A ViewModel defines the information and actions needed by a particular use case without changing the domain model. Create a separate ViewModel when a consumer needs a selected subset of a class rather than the full class.
For example, a House phone view can expose the address and position needed by a field user while omitting other attributes and navigations. The same ViewModel can provide the data definition for a rendered UI or an interface for another system. A ViewModel can read and write system data and run actions, which makes it suitable for an API service or a native mobile-app backend.
Add C# without changing generated files
MDriven Framework generates code as partial classes. Put your hand-written C# logic in separate partial-class files rather than editing generated files. MDriven preserves those separate files when it updates generated code after model changes.
For example, when an integration requires domain behavior that is not represented as an OCL rule or ViewModel action, add that behavior in a separate partial class for the generated domain class. Keep the model as the source for the class structure, database schema, and generated mapping information.
Integrate external systems
Use REST API integrations to plug external services into an MDriven solution. You can also use a ViewModel as the boundary for an API or web-service interface: define the data, write operations, and actions that the external consumer needs instead of exposing the complete domain class.
For example, an external mobile application can use a ViewModel-based service to retrieve a selected set of records and invoke an action. This keeps the mobile use case separate from the full domain model and its other consumers.
Customize rendering and delivery
Use declarative UI customization when the change is limited to UI behavior. OCL expressions can control behavior such as visibility and styling. Use custom templates when a provided rendering must be replaced.
For example, hide an input when its ViewModel expression evaluates to false, or provide a custom rendering for a view that needs a different presentation. MDriven Framework is UI agnostic at its core and includes declarative ViewModel engines for several UI technologies; keep the ViewModel focused on the use case so the presentation can vary without changing the domain model.
Extend persistence and modeling
MDriven Framework derives database schema, domain-class code, and mapping information from the model. Its PersistenceMapper interfaces support database-specific persistence behavior and can be used to create additional mappers.
For example, when your target database is not covered by an available mapper, implement a custom PersistenceMapper rather than hand-maintaining the model-derived schema and mapping. Database Evolution updates the schema when the model changes while preserving data.
For model-environment extensions, MDriven includes declarative model plugins and model plugins with code. Use these when the extension concerns model-level behavior rather than a single ViewModel, UI rendering, or domain-code addition.