I normally utilize the “Web Service Software Factory” to structure and implement my services.  This package greatly decreases the time spent on the mundane tasks of exposing your business logic to the service layer. 

One could argue that exposing business logic is quite simple, add a WCF service to your project and write your business logic in the *.svc file.  However, we are here to write loosely coupled code.  To this end, one can use multiple dynamic link libraries (.dll) to organize one code.  Moreover, by judicially choosing where objects belong, one can apply the principles of separations of concerns.

The “hands on lab” for the web service factory is top notch.  The modeling edition allows one to use a graphical approach to define data and services contacts quickly and correctly.  Below are the data contract and the service contract files needed to expose a service with a DBinsor configuration file.  Furthermore, I have included the projects contained in the solution file.

Data Contract:

         Service Contract:

         Solution:

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.

We have decided to upload the source code for this project to the MSDN Code Gallery.  The code gallery site should be functional by April 6^th, 2008.  If you have an interest in joining this project please contact me, by email, through the blog site.

Here is my preliminary table schema.  Tomorrow we will probe into how my assumptions influenced its design.

Second, never swallow exceptions.  By swallowing exceptions, I mean try catch without alerting the user.  Moreover, write the exception to the event log; lost exceptions don’t help the debugging process.  In general one should throw an exception early and cleanly allow for appropriate remedies.  This is concept best taught by example.

There are many takes on the agile development process: SCRUM, TDD and Extreme Programming to name a few.  One of the most important, in my estimation, from the agile manifesto is: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

            With this in mind, my first function is simply to design a database and extract a compatible IResource for the Castle Windsor Container.  In actuality this process was quite trivial [a Sunday afternoon] with the new technologies of .Net 3.5.  Moreover, it will take me much longer to explain what I did; than actually do it.

            In my next post, I will delve into the database design.

I had a professor in graduate school who once said that Computer Science, as an educational institution, is backwards.  Furthermore, he went on to say that in no other field do professors teach without practical experience. For example, a professor of trial law would not teach how to cross examine a defendant if one did not have the corresponding experience.  Nor would a professor of surgery explain the procedure of a heart transplant, if one did not have multiple transplants under one’s belt.

            Obviously, the previous statement is quite general and a bit drastic.  Nonetheless, as I interview prospective employees I am very disheartened by their conceptual knowledge of the field.  

Out stems a few questions:

How has our industry come to such a state?

How can we educate better?

As a .Net Developer, we are in a whirlwind of new ideas, technologies and practices.  Thus, it is an exciting time as well as a crucial time to educate as we do along.

The purpose of my blog is to educate on ideas, technologies, and practices from my personal experiences.