AddIns and Databases: Best Practices for Modularizing Data Access? RRS feed

  • Question

  • Acropolis Team:


    There has been much chatter recently about modularization through addins, but little discussion of modularization of heavyweight data access under an addin.  The Calculator Example shows us how to marshal lightweight data (an obect), but not heavyweight data (SQL Server's TDS).


    Consider the following scenario:


    An accounting system has what one would call a core database with core tables accessed by core modules.  One could consider these the Gestalt of the accounting system, the absence of which would corrupt the identity of the system.  Accounting systems often have additional modules which, until recently, could not have been easily implemented around an addin model.  With the advent of .NET component technologies and System.AddIn, however, this approach has become more feasible, more attainable.


    Let's say we have a module called InventoryInventory will need access to core tables, but will also have its own tables (which the host should not access).  Relationships between core tables and Inventory's tables will need to be created dynamically (since the customer may not have purchased the Inventory module at the outset).


    We're trying to figure out the best practices for such a scenario.  Should each addin have its own database, a database managed by the same instance under which the core database is managed?  Or, should the addin be permitted, through a pipeline, to create its own tables in the core database?  What are the penalities for cross-database relationships?  What about the approach of one server instance per addin?  Does the isolation of addins within AppDomains require a corresponding physical isolation of their underlying data in a database?


    In an initial attempt, we had created the addin's tables in the core database a priori, which rendered the addin model moot. The host, of course, should have no advanced knowledge of addin schemata.  It seems that hosts and addins should adhere to [at least] the following principles:

    • Addins should have an intimate knowledge, through indirection, of the host's schema (i.e whatever the host chooses to expose)
    • Addins should be permitted to dynamically create relationships between the host's schema and its own
    • Hosts should have no direct knowledge of, or direct access to, the addin's schema
    • Through a well-defined publisher-subscriber interface, hosts should be allowed to respond to data access events generated on the addin side, and vice versa

    Notice that the discussion of design revolves around data access, not around higher-level constructs such as contracts, adapters, etc.  The structure of a System.AddIn and the structure of data access may not move in the same direction.  (For example, addins may need access to each other's data).


    Does Acropolis address best practices in terms of the architecture necessary to modularize data access in the foregoing scenario?


    Thank you.


    Eric, et al.

    Saturday, September 22, 2007 4:39 PM


  • Hi Eric,

    Thank you for your feedback. We will keep this in mind as we design WPF Composite Client.

    Thank you,

    Kathy Kam

    Program Manager


    Tuesday, October 30, 2007 2:06 AM