Excellent article, easy read.
I am not a dot NET developer, but am trying mightily to come up to speed on it. I have been involved in relational databases since the days of SQL/DS on VM and DB2 V1 on MVS. This is the first I've heard of the Enterprise Library. I had been slogging through the samples. etc. in the Express sandboxes so conveniently furnished by MSFT and, while comfortable with the concepts, was getting bogged down with the detailed implementations.
I look forward to messing with this new library.
Thanks for a good read.
Nice article!
Public Class DataAccessLayer Private dB As Database Sub New() 'Instantiates the database factory class. This decouples the database 'methods from the underlying database, making it easier to change 'database types, e.g. SQL to Oracle dB = DatabaseFactory.CreateDatabase() End Sub Public Function GetPreviousStatus(ByVal PurchaseOrderNumber As Long) As Integer Dim objCommandWrapper As DBCommandWrapper = _ dB.GetStoredProcCommandWrapper("dbo.StoredProcedure") objCommandWrapper.AddInParameter("@Parameter", DbType.Int64, PurchaseOrderNumber) Try Return dB.ExecuteScalar(objCommandWrapper) Catch exc As Exception Throw New Exception("An Error Occured whilst querying the Database") End Try End FunctionEnd Class
I agree with your architect, the time saved is worth the minimal performance hit. Abstraction layers like these are very much worth doing. Standarding data access is a key concept and all the better if you're using something that developers coming from other companies will understand.
As much as I like abstraction, I do think it's pretty important that developers spend some time working with the raw components of ADO.Net first, then they'll both appreciate the power/simplicity of the abstraction layer and they'll be able to bypass it if/when it ties their hands too much.
I dunno about others but I really hate it that things like Connection Strings are stored in plain text in the web.config file. What bugs me even more is that things like the enterprise library build upon that assumption and do not seem to allow for exceptions for how you might rather handle it. For instance, I at the very least want to encrypt my password but it doesn't allow for that. I haven't checked out the latest version (we are using an older version) but this still seems to be the case. The example here used a different security context so it wasn't an issue but most connections are going to require a userid and password that you want to run your queries or procs under. Does anyone have any thoughts or ideas about how best to use the enterprise library to accomplish a more secure connection string? I know no one can get at the config file from outside the company but I think someone inside a given company could easily know where to look to get at credentials for sql server given this approach. All they got to do is gain access to the machine or to source safe etc...And knowing that this is how most vb and asp applications work (even without using the enterprise library) seems to make it all the more easier for people to know where to find this info. This "rant" is more an issue for dot net forum so I apologize in advance. But I would like to hear if others have the same concern.
