Today I lost faith in yet another source control system when combined with .NET. So far I have been disappointed by Visual Source Safe (who hasn't?), Perforce (don't get me started) and now PVCS. Maybe the common theme is poor VS.NET integration hooks? I'm not sure, but the only source control system that has consistently satisfied me day in and day out is SourceGear Vault. At least Eric Sink and team use their own product from within VS.NET and experience (and thus fix) the same frustrations that the plague the common developer within Visual Studio. Here's to hoping that in the 2005 versions of .NET tools the integration is much improved . . .
I am currently working with the Microsoft Enterprise Library and have implemented the Exception, Logging and Data Access blocks (and thus Configuration since it is used by these). At first I was concerned that the Data Access block had taken a step backward and left out the ability to work with strongly typed datasets. The documentation makes no explicit mention of how to use strongly typed datasets and focuses instead on filling a standard dataset by using the ExecuteDataSet() method. I poked around in the source code a bit and noticed that ExecuteDataSet() is actually creating a new DataSet and passing it to LoadDataSet() to do all the heavy lifting. I also found a little bullet point in the "fine print" Usage Notes section of Using a DataSet to Retrieve Multiple Rows that says:
If you want to reuse an existing DataSet instead of creating a new one to hold the results of your query, use the LoadDataSet method in the Database class.
Interesting. . . and it works with existing Typed DataSets too! Simply execute the following command to populate an existing instance of a Typed DataSet:So far the Enterprise Library saves a lot of coding time on the relatively small appl that I am building and has kept me from spending too much time on the details of data access, exception handling and logging (to event log, e-mail and more). It has also allowed me to implement encryption of db connect strings in config file for "free", so there are nice little benefits like that thrown in. If the solution should ever be moved to Oracle or DB2, that will be a painless transition as a result of the Enterprise Library. A more likely scenario in in this case would be that it is moved to Sybase - this would require me to develop a class for Sybase particulars, but it would be relatively cookie-cutter and again would save me a lot of time by using the Enterprise Library. I am not sure that the Enterprise Library is the ultimate answer for a large-scale solution, but for small line of business apps it will potentially save you many days of development time.
VB: myDB.LoadDataSet(myCommandWrapper, CType(myTypedDS, DataSet), "DataTableName")
CS: myDB.LoadDataSet(myCommandWrapper, (DataSet)myTypedDS, "DataTableName");