***Disclaimer: This information applies to Visual Studio 2010 Beta 1 only.***
In the first part of this series I described general concepts around the ModelBus infrastructure. In this second part I will describe the model bus service and how MEF is involved.
The ModelBus as a Service
The Microsoft.VisualStudio.Modeling.Sdk.Integration.Shell.10.0 is a VS Package that defines one core service, the IModelBus service.
The model bus service creates and uses its own MEF composition container with two directory catalogs pointing to:
- %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions
- %VS10_Install_Dir%\Extensions
A DSL exports an adapter manager and provides some metadata to specify which adapter this manager manages:
[Export(typeof(ModelBusAdapterManager))]
[HandlesAdapter(“MyAdapterId”)]
public partial class MyAdapterManager : VsModelingAdapterManager
{
…
}
The main responsibility of the model bus is to find registered adapter managers, for that the composition container is used:
container.GetExportedObjects<ModelBusAdapterManager>()
In order to register a DSL with the model bus we need to do the following steps:
- Update the model definition to introduce a domain property that will hold the model reference
- Update the model serialization behavior to include the model reference serialization
- Create an adapter for the DSL
- Create an export an adapter manager for the DSL
- Deploy the DSL under extensions (done automatically at compilation time via the VS SDK msbuild target)
Stay tuned,
Pablo
***Disclaimer: This information applies to Visual Studio 2010 Beta 1 only.***
One of the new main features of the new version of the DSL toolkit is the “ModelBus”. The model bus basically allows a model element to reference another model element (ModelBusReference). These two model elements could be defined either in the same DSL or in different ones. With a ModelBusReference we can do interesting model interactions such as navigating the references back and forth, performing validation across models, etc.
The ModelBus infrastructure lives in two core assemblies:
- Microsoft.VisualStudio.Modeling.Sdk.Integration.10.0
- Microsoft.VisualStudio.Modeling.Sdk.Integration.Shell.10.0
Microsoft.VisualStudio.Modeling.Sdk.Integration.10.0
As the name implies, this assembly contains concepts that are totally decoupled from Visual Studio.
The main generic concepts are:
ModeBusAdapter
Is a bridge between the model bus and the underlying model. Therefore each model has its own adapter.
It’s main responsibilities are:
- Get all references of an element type
- Resolve a reference into an object
- Get the view associated with the model
ModelBusAdapterManager
Is used to create and control the lifetime of adapters.
It’s main responsibilities are:
- Create adapters
- Create reference to a model
- Return the list of supported adapters
- Return the list of exposed element types. An exposed element type is an element that can be referenced by another element
ModelBusReference
Encapsulates information about a reference in the model bus. It is composed of:
- Adapter reference
- Adapter id
- Model display name
- Element display name
It is being serialized as:
ModelBusAdapterReference
Represents the base class for adapter references
ModelBusView
Allows a client to manipulate the design surface of the model (if applicable)
It’s main responsibilities are:
- Open view
- Close view
- Show view
- Hide view
- Select UI elements
Then we have a set of derived classes that are specific to DSLs:
- ModeBusAdapter<- ModelingAdapter
- ModelBusAdapterReference <- ModelingAdapterReference
ModelingAdapter
Represents the base class for DSL based adapters. In this case the model is a DSL model.
ModelingAdapterReference
Encapsulates information about a model element reference, it is composed of:
- Model element id
- View id
- Model file absolute path
It is being serialized as:
Microsoft.VisualStudio.Modeling.Sdk.Integration.Shell.10.0
In this assembly there are concepts that are coupled to the Visual Studio infrastructure.
VsModelingAdapterManager
This adapter manager introduces the notion of document handlers that knows how to handle a DocData concept.
VsModelingView
This implementation is tied to the DocView concept.
Stay tuned,
Pablo
