Early this morning I wrote an assembly schema provider for CodeSmith. It uses reflection to return objects as tables and properties as columns. Pretending that an assembly is a database is useful in many ways especially if you have started with the object and not the database design. I get into the reasons I wrote the provider at the end of the post as I don't want to bore those that quite frankly don't care why I did it.
Here is the result of my efforts: AssemblySchemaExplorer Binary.zip and AssemblySchemaExplorer Source.zip
Using the Schema Explorer
The display of custom schemas in CodeSmith 2.6 does not appear to be supported, so to use the provider you need to CodeSmith open the file:
C:\Documents and Settings\<user>\Application Data\CodeSmith\SchemaExplorer.config
and add the schema prover manually, as per the example below:
<configuration>
<schemaExplorer>
<dataSources>
<!-- Note that the connection string parameters must end with a semi-colon -->
<add name="Example Objects"
connectionString="Assembly=C:\Development\Example\BusinessLayer\bin\Example.BusinessLayer.dll; ObjectFilter=Example.BusinessLayer.Framework.BusinessBase;"
providerType="SchemaExplorer.AssemblySchemaExplorer, SchemaExplorer.AssemblySchemaExplorer"
selected="true" />
</dataSources>
</schemaExplorer>
</configuration>
And that's pretty much all there is to it. The list of tables you see in the view should be the target objects with their namespaces. Please note that the namespace is placed in the owner of each "table".
Features
- Represents objects as tables
- Displays public properties as columns
- If an object contains a property with the same name as the class and an Id suffix, it will return that as the primary key of the object
A Few Possible Uses for the Schema Explorer
Here are just a few things that one could generate with the explorer:
My Motivation for Writing the Provider
Those of us that have used CodeSmith know that the idea behind it is to use a database as the starting point for one's code and then take it from there. While I've used this approach on various projects, the project I'm currently working on has quite a complex database structure. This has meant that working with objects that approximate the database is very tedious and confusing to the UI developers. I decided to rather opt for a far more object oriented approach and design the objects in a fashion that would maximise the UI developers productivity and shield them from the complexity of the underlying persistence structure.
I first designed the objects in Visio and then use that to generate my code. Unfortunately I discovered that the code that it generated was not only quite ugly but also not very useful and required a significant amount of hand coding. We are now at the next phase of the project where we needed to map the objects to the database using a standard DataMapper pattern. To hand code all of that seems like a waste of time frankly. Unfortunately our objects are so different in structure that to use a SqlSchemaProvider as the basis of the datamapper classes is not going to really work. If I could use the business objects as the source however the process would be a lot less painful. Of course we have not avoided hand coding since we are still going to still complete the object/data structure mapping but the generated code should compile at least.