Background

Microsoft Domain-Specific-Language Tools for Visual Studio allow the developer to create a modeling language and a graphical designer which will allow the end user to model a problem domain. This diagram and the corresponding model can be used to generate artefacts, most commonly code, used in developing applications. This allows the application of the development paradigm "Domain Driven Design". The models are usually made up of Model Elements and Element Links commonly represented by Shapes and Lines in the diagrams.

Visual Studio DSL Tools

The DSL tools can drastically increase productivity by enabling the user to model common scenarios and generate code, thus reducing repetitive tasks leaving the end-user (developer) to concentrate on more tricky areas. The generation templates can then be changed to support evolution and refinement of the implementation and regeneration of output will again reduce repetitive unnecessary churn.

DSL developers often run into a number of common issues when developing the modeling language. The first is that models can become very large, very quickly. This can often be reduced by being strict about the rules of domain drven design, i.e. reduce the scope of the domain and make the domain independent of other domains. Sometimes though, life would be made a lot easier if we could create a link from an element on one diagram surface to another element on another diagram surface. There is no native support for this in the DSL tools, although for Visual Studio 2005 Microsoft did release an unsupported tool called the Microsoft Designer Integration Powertoy. The other problem DSL developers often faced was how to represent a path taken through a model, following links from element to element. The DSL Cross Model Framework aims to solve these problems amongst others.

Problems with the Designer Integration Service Powertoy*

  • The DIS would often lock DLLs in a solution
It would seem that the DIS tried to look for model files in the current solution and also in the embedded resources of references. Although the reference code was never fully implemented it did try to open referenced dlls in the same appdomain as the service itself, it also loaded dlls for references in the same solution, this meant that project output dlls were locked at compile time and visual studio had to be restarted. DCMF gets around this problem by loading references in their own appdomain to extract model files in embedded resources.
  • The DIS would seriously affect performance in large solutions
There was no caching of information in the DIS therefore performance would become a problem. Each time the DIS was used to access another model file, the solution and its references would be scanned for models and those models would be deserialized. DCMF only loads models as they are needed and invalidated the model file list by listening to certain events within visual studio.
  • No official version for Visual Studio 2008
No official release of the DIS was made for Visual Studio 2008, although a version is available with the Web Service Software Factory. DCMF is designed to work with Visual Studio 2008.

Last edited Jun 29, 2008 at 9:40 AM by PeterG, version 3

Comments

No comments yet.