You can use MDriven Framework to build .NET applications from a UML domain model while keeping generated code, database structure, and your hand-written C# code aligned; this overview is for developers planning, starting, or maintaining a Framework application.
What MDriven Framework does
MDriven Framework is a model-driven framework for .NET applications. You define the application domain in MDriven Designer, MDriven's UML modeling tool, and use that model as the basis for generated domain code and database schema.
For example, if your model contains a Customer class with a name and a relationship to Order, the model supplies the information from which Framework derives domain classes, persistence mapping, and database tables. When the model changes, Framework can update generated code and evolve the database schema while preserving existing data.
Read MDriven Framework – a Model driven framework for the product-level description and supported framework capabilities.
Choose the right MDriven product
MDriven Framework is for developers who want to work with strongly typed C# code against the types and classes defined in their model. It is the larger development environment relative to MDriven Turnkey, which can use Framework code to implement methods and derivations.
| If you want to... | Start here |
|---|---|
| Understand the MDriven products and where Framework fits | MDriven Product Line |
| Learn the model-driven Framework approach, generated artifacts, and persistence capabilities | MDriven Framework – a Model driven framework |
| Move a model created in MDriven Designer into a Framework project | Moving your work from MDriven Designer to MDriven Framework |
| Use Framework code with a Turnkey application | MDriven Framework and Turnkey |
The development workflow
Use the model as the common definition of the domain, then add application-specific behavior in C#.
- Create or open the domain model in MDriven Designer. Model classes, their properties, and relationships. For example, model
CustomerandOrder, then connect each order to its customer. - Generate or update the Framework artifacts from the model. Framework derives domain code, database schema information, and mapping information from the model.
- Add custom C# behavior to the generated model types. Framework supports generated C# and VB.NET code; use your custom code for behavior that is specific to the application.
- Build and run the application against the configured persistence store.
- When requirements change, change the model first. Update the generated artifacts and database schema, then build and test the result.
This workflow is important because the model change is the starting point. For example, adding an Email property to Customer is a model change; after updating the Framework artifacts, the generated domain and database structure can reflect that new property.
Generated artifacts and custom code
Framework derives several parts of an application from the model:
- Database schema.
- Domain-class code.
- Information that maps model classes to database tables.
You can extend the generated model with application-specific C# code. Keep custom behavior separate from generated output so that you can update the model-derived code when the model evolves. A typical use is to add a method or derivation to a modeled class and then consume that strongly typed class from the rest of the application.
For guidance on using custom Framework code from a Turnkey solution, see MDriven Framework and Turnkey. For Turnkey generic-code debugging, see Debug Turnkey Generic Code.
Persistence and database evolution
Persistence is the mapping between model objects and stored data. MDriven Framework derives persistence mapping and database schema information from the model. The framework supports persistence mappers for several databases, including SQL Server, Oracle, MySQL, Firebird, Mimer, NexusDB, SQLite, Blackfish, and Sybase.
Database Evolution is the process of updating the database schema after a model change while preserving existing data. Treat it as part of normal model maintenance:
- Make the intended change in the model.
- Update the generated Framework artifacts.
- Apply the schema evolution as part of your development and deployment process.
- Verify that existing data and the changed model behavior are correct.
For example, when a new property is added to a modeled class, verify both that the application can use the property and that existing stored objects remain available after the schema update.
Runtime capabilities
Framework also provides optional domain-runtime capabilities. These include:
- A domain-layer undo and redo stack.
- Versioning for selected classes.
- Declarative Action definitions.
Use these capabilities when they fit the domain behavior you are modeling. For example, a user editing a set of related domain objects can use the domain-layer undo and redo capability rather than implementing separate state tracking for every object change.
User interface options
MDriven Framework is UI-agnostic at its core. It includes declarative ViewModel engines for WPF, MVC, Windows Store, Silverlight, ASP.NET, and Windows Forms.
A ViewModel is the model-facing representation used to supply state and behavior to a user interface. Choose the UI approach that matches the application you are building, while keeping the domain model and its generated Framework code independent of a particular UI technology.
For WECPOF-related UI work, see WECPOF.
Moving an existing Designer model
If you begin in MDriven Designer and later need the full Framework development environment, follow Moving your work from MDriven Designer to MDriven Framework. That guide covers the project move and explains that Framework stores models in the multi-file, uncompressed ecomdl format. This format is intended to work well with diff tools and source-control systems such as Git and SVN when multiple developers change the model.
You can continue to open the ecomdl model structure in MDriven Designer after the move.
Maintenance and troubleshooting
When changing Framework versions, start with the documented clean, code-update, and rebuild procedure. If that does not resolve compile-time errors, follow the remaining uninstall and Global Assembly Cache (GAC) cleanup steps in Downgrade MDriven Framework version.
Do not change Framework versions while Visual Studio or applications connected to the solution are running; the downgrade guidance warns that doing so can leave residual files or assemblies.
API documentation
Use API documentation when you need the Framework API reference while implementing or reviewing custom code.