Visual Studio 2005 introduces a rich new environment for developing database applications against third-party data sources. While Visual Studio has always offered design-time support for SQL Server development, other data sources have posed more of a challenge.
Now, DDEX extends the Visual Studio design-time experience by allowing Visual Studio components like Server Explorer and designers (including custom designers) to interact with third-party data sources and their object hierarchies, enabling both visibility and programmability.
What Is DDEX?
DDEX defines a systematic approach to extending data designers and data-related features of Visual Studio 2005 to object hierarchies provided by third-party data sources. This allows design-time access to the external data source objects and entitles them to "full citizenship" in the Visual Studio design time experience.
DDEX enables this high-level extensibility by providing a library of managed classed (the DDEX managed class library) that allows you to implement a Visual Studio extension to a .NET data provider. Such an extension implementation is called a DDEX provider. This DDEX provider, in conjunction with a technology-specific .NET data provider, drive your data extensibility implementation.
You can use DDEX to extend the following Visual Studio features:
Data Connection and login dialog boxes
These dialog boxes are frequently specific to a data source. DDEX allows a provider to expose its own control that can be hosted in the Visual Studio Data Connection dialog box, and be used when connecting to that data source.
You can enumerate objects from the data source for display as hierarchy nodes in the Visual Studio Server Explorer; you can control which objects to enumerate and how they should be presented in the UI.
You can drag-and-drop data object nodes from the Server Explorer onto data designers.
A DDEX provider can supply custom designers, in place of default Visual Studio designers, to view and edit data objects. For instance, you may use your own table designer to view and/or edit tables from your data source.
In addition to making the integration easy, DDEX also provides a common model for all data providers – simplifying both the implementation as well as providing a common user experience.
Overview of DDEX Architecture
Viewed structurally, a DDEX implementation is composed of four key parts:
The DDEX component (#3) is composed of two key parts: (a) DDEX services, and (b) DDEX support entities.
Support entities are quite simply a set of managed classes that are implemented to provide specific Visual Studio extensions. In fact, it is the implementation of these support entity classes that constitutes a DDEX provider.
Broadly speaking, DDEX support entities fall into three categories:
DDEX services expose functionality that has been provided by the support entities. Some of the more important Visual Studio services include the following:
For an extensive discussion of implementation details for creating your own DDEX provider, including four samples, you can download and install the DDEX SDK, which is part of the VSIP installation (currently in beta version). Note that the VSIP 2005 beta version provides documentation that is presently incomplete.
Nick Gattuccio, DDEX SDK Writer
Milind Lele, DDEX PM
Stephen Provine, DDEX Lead Developer
Another milestone in the ADO.NET vNext train -- the Entity Data Model designer prototype has just been pushed to the web. In earlier iterations I have seen, this tool was more stand alone applications, so it's good to see it...
PingBack from http://woodtvstand.info/story.php?id=9254
PingBack from http://thebasketballhoop.info/story.php?id=1770