The MSDN Code Gallery is finally setup.  Prior to uploading a code sample, I would like to make a bit of headway in the documentation process.

Prior to starting this conversation, I will make the assumption that one has completed the “Getting Started Project”.  Moreover, in the RC3 Documentation, I would recommend reading the “Concepts” and “User Guides” sections.

            Last week I uploaded a database diagram without much explanation.  I plan to rectify that shortcoming in this post.  When perusing the Castle Windsor documentation, the Windsor configuration reference was extremely helpful in the design of the database.

            Reading the tags in a top down manner, I decided the “includes tag” was not necessary in a database scenario.  The “includes tag” is useful when one does not want to keep all configurations in one file.  However, since we are keeping all configurations in a centralized database, the use of multiple configuration files is unnecessary.  Similarly speaking, “global properties” are superfluous because of the database.  However, the conception of “global properties” will be addressed on the database graphical user interface (GUI).

            “Facilities” are very powerful in that they allow one to extend the container.  Nonetheless, they are out of scope in this preliminary version of D-Binsor.  Similarly, the concept of “interceptors” will be left for future version of this library.

            The heart and soul of this configuration file lies in the use of “components” coupled with “parameters”.  With this in mind, the first table I created was the Contracts Table. 

In general, I create a primary key, “Id”, for all my tables to make table to table relationships easier.  Many would not name the primary key for each table the same, though I found with LINQ to SQL to find the unique identifies in the corresponding object is much easier.

In the theme of trying to be succinct, I will explain the key design choices I made.  My first large choice was that every implementation must have a contract.  Windsor does allow for one to register classes which have no associated interface.  However, I feel that in a large scale SOA systems, where “D-Binsor” will be most useful, there is very little drawback to interface programming.  Furthermore, the extensibility benefits from interface programming, for example “Mocking”, are quite compelling.

This decision allows for function parameters to only be defined on a contract basis.  Thus, we have concluded the right side of the diagram.  Before we discuss the left side, one issue with this design is that one could create two contracts in the same namespace with the same signature and receive no database warning.  Obviously, that is unacceptable in the programming space [we will have to tackle this problem in the business layer].

One of the goals, beyond data storage, of a database should be data integrity.  That is the database should not allow one to enter data which breaks business rules.

The left side of the diagram allows one or more castle configuration files to utilize the contract implementation structure defined above.  Generally, one would create a new configuration file by adding data to the castle table.  From there one could register components and component parameters to generate the correct configuration file.

To reiterate, one of the goals of a database should be data integrity.  In that vein, we should utilize non-null foreign key relationships.  For example, the implementation table must have a non-null contract id.  Moreover, we should use a unique key when necessary.  Though it is not visible in the diagram, in the contract parameters table the combination of the contract id and name fields should be unique.