A package is a container that you use to organize related MDriven Designer model classes, associations, and other model definitions; it is for modelers who need to divide one model into understandable, reusable sections.
Organize a model with packages
A model can contain several packages. Put definitions that belong to the same area of the application in the same package.
For example, a library model could use separate packages for:
- Books: classes such as
Book,Author, andPublisher. - Loans: classes such as
LoanandReservation. - Users: classes that represent library users and their access details.
This structure lets you work with one part of a larger model without treating all classes as one unstructured list.
Build a package hierarchy
A package can be owned by another package. Use ownership to create a hierarchy when a model area needs further subdivision.
For example, you can place a Books package and a Loans package inside a parent Library package. The parent package groups the complete library area, while its child packages keep the class definitions focused.
Package naming and default association names
The package name can affect default names suggested for associations. When a package has a plural name ending in s, associations to a class in that package can receive a plural default name.
For example, if Book is in a package named Books, an association end that represents many books may be given the default name Books.
Use clear, domain-oriented package names. This makes suggested names easier to understand, but review every generated or suggested association name to ensure it matches the meaning of your model.
Apply a common superclass
All classes owned by a package can share a common superclass. This is useful when the classes need common inherited behavior or structure.
For example, if all classes in a package should inherit from SysSuperClass, set that common superclass for the package rather than configuring each class separately. See MDrivenStart:MDrivenStart Package for the package-oriented starter-model guidance that describes this use.
Reuse packages between models
You can export a package from one model and import it into another model. This supports reuse of a self-contained area of a model.
When deciding how to reuse a package, distinguish between an imported package and a referenced package:
| Reuse approach | What you can do | Update behavior |
|---|---|---|
| Import a package | The package becomes part of your model and you can edit its contents. | Your model owns the imported definition. Code generation creates code and empty stubs for code-implemented operations in that package. |
| Reference a package | Use its classes and create allowed associations to and from them, but do not edit the package definition in your model. | The referenced package is not generated together with the rest of your model. It normally has its own compiled assembly or project. |
For example, import a package when you want to take ownership of a reusable set of classes and adapt it for your application. Reference a package when you want to use an external model definition without changing it.
Read Documentation:Segmenting definition and logic before choosing an approach. For the editing limits on referenced packages and how to adopt a reference as your own copy, see Documentation:Referenced package.
Use classes from a referenced package
Classes in a referenced package are read-only in your model. You can create associations to and from those classes only when the association does not add a new navigable end embedded in the read-only package.
In practical terms, your classes can point to a read-only class, but a read-only class cannot be changed to point to a new class in your model. This preserves the external package definition.
If you later need to change the referenced classes themselves, adopt the package through Import/Export. Adoption creates a copy that you own, but that copy no longer receives updates from the original source. See Documentation:Referenced package for the adoption behavior.
Control namespaces in generated code
A package has an AdditionalNamespaces property. Use it when generated code needs additional namespaces.
Enter a comma-separated list of namespaces in Package.AdditionalNamespaces. For code-generated ViewModels, MDriven uses the AdditionalNamespaces value from the root class's package.
For example:
System.Collections.Generic, System.Linq
For the precise generated-code behavior, see Documentation:Namespace in generated code.
Package design checklist
Before you export, import, or reference a package, check the following:
- Keep classes that represent one domain area together.
- Use a package hierarchy only when it makes navigation clearer.
- Choose package names that produce meaningful default association names.
- Apply a common superclass only when all owned classes should inherit from it.
- Import a package when you need to edit and generate it as part of your model.
- Reference a package when its definition and implementation are maintained externally.
- If you use a referenced package at runtime, ensure its required assembly or project is referenced and that the required packages are selected for use, as described in Documentation:Segmenting definition and logic.
Examples of reusable packages
MDriven provides packages for specific concerns. Use their dedicated pages for setup and usage instructions rather than copying their definitions into unrelated packages:
- Documentation:Calendar package for calendar dimensions and date-related model data.
- Documentation:Asp.Net Identity package for the available ASP.NET Identity package download.
- Documentation:Password Reset Package for the password-reset model package.