Re: .netTiers and Windows Azure?

I am not an azure expert....I know next to nothing about it.

Great question.  Nettiers requires relational model that Codesmith can read to generate code.  Not sure how SDS would translate into that world.  Now, if you can design a model in Sql Server, host that in Azure somehow, then maybe.

Feel free to continue this discussion...it would be really sweet to get it working.

jeff

Thanks Jeff - here's a summary of what I found out that I hope can help.  A couple of days ago, I found the following video was published on MSDN:

How Do I: Store Data in Windows Azure Tables?
http://msdn.microsoft.com/en-us/azure/dd483299.aspx

The first few minutes of the video provide a lot of good information and I think a potential solution for making .netTiers work with Windows Azure.  Here are some of my notes from the video:

• From what I understand the current implementation of Windows Azure Storage occurs through an HTTP based REST style interface.
• That said, in the Windows Azure SDK Microsoft gives us another alternative: a managed set of classes that wrap the HTTP calls to Azure storage.  You'll find these in the 'Samples' directory of the Windows Azure SDK, add a reference to "StorageClient.dll" (you can then use Microsoft.Samples.ServiceHosting.StorageClient).  You also need a reference to System.Data.Storage.Client.
• In Windows Azure tables, the basic unit of storage is called an Entity, so for each type that you want to store in a table you create a class that derives from TableStorageEntity (present in Microsoft.Samples.ServiceHosting.StorageClient).
• TableStorageEntity provides two properties: PartitionKey and RowKey.  These are the only two properties that Azure storage requires for entities and the only two properties that it really cares about.
• PartitionKey is used by Azure Storage if it needs to distribute the table entities over multiple storage nodes.  For example, if you have a table of books, your PartitionKey could be the "author" property; this way books from the same author will be stored in the same Azure storage node, so our queries would be more efficient.  The video above mentions that another video will have more information on table partitions.
• RowKey represents the unique id of the entity within the partition it belongs to.  For the book table example, the rowkey was set to the book's title - so each book could be indetified by it's PartitionKey (author) and RowKey (title).
• When you deploy your application to Windows Azure, your data is ultimately stored in Azure Storage.  But you can create a local "Storage Table Class" to interact with programatically - for this you can create another wrapper class that derives from Microsoft.Samples.ServiceHosting.StorageClient.TableStorageDataServiceContext (in the example they call this class BookTable)
• Within TableStorageDataServiceContext there's a method to load the configuration (so you don't hard code values), StorageAccountInfo.GetDefaultTableStorageAccountFromConfiguration().  You need to add the configuration settings to a couple of services xml configuration files.
• AccountName, AccountSharedKey and TableStorageEndPoint are defined in the XML file ServiceDefintion.csdef
• The actual values for AccountName, AccountSharedKey and TableStorageEndPoint are defined in in the XML file ServiceConfiguration.cscfg
• While in development, you can use the local storage development account, so your TableStorageEndPointis something like "http://127.0.0.1:10002".
• There's a "Development Storage" desktop app that allows you to check if your local TableStorage is running (and start it if needed).
• Going back to our BookTable class (the one that derives from TableStorageDataServiceContext), we can now create a method to perform a query against our Azure table storage that returns all entities that match a given type.  In the example this was a "DataServiceQuery<Book> Books()"

There's a lot more info on the video, including a way to create the table in Azure storage on a first request, based on the classes discussed above.  In the video, they mention that this was written for ASP.NET users, since each HTTP call to an ASPX page generates an new instance of the page class.  But I found it interesting that there's a mechanism to create the storage tables in Azure based on our classes - and only once!

With the above in mind, here's an idea on how .netTiers could work with Azure storage:

1. We define our schema in our local SQL Server, just like we do today.
2. We run CodeSmith and load up a future version of .netTiers that has support for Azure Storage integration.
3. The .netTiers templates would retrieve the schema for SQL (like today), but would create the classes discussed above.  Parameters could be specified to generate the correct XML configuration files as well.
4. In the .netTiers configuration you would specify if you are using SQL Server or Azure Storage.
5. There would be a mechanism to detect on first run that the tables need to be created in Azure Storage (see video).

We then end up with the same tables we had in SQL, created in Azure Storage (locally or in the cloud!).  We can use our standard calls to .netTiers that we all love to manage our data.

This would be great not only for new projects, but if it works it would mean that existing projects could continue using the same code - instead of saving to SQL Server, the new .netTiers wrapper classes would write to Azure Storage.

What do you think?

Update - I posted this info on my blog as well: http://blog.ehuna.org/2009/02/how_do_i_store_data_in_windows.html