The Enterprise Library for .NET Framework 2.0
-
Comments posted to this topic are about the content posted at temp
-
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!
Just a quick point.
I know the author isn't from a .Net background, but a slight improvement to the code would be to use a class level variable to store the return from DatabaseFactory.CreateDatabase(). This can then be used throughout a complete "data tier" class.
eg.
Public Class DataAccessLayerPrivate 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 Function
End 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.
-
If you follow Neil's advice and keep a reference to the Database object then the "slight performance hit" should only apply the first time the procedure is called. This is a little more complicating with ASP .NET apps based on the caching method but for WinForms apps it's pretty awesome.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
Very Nice! Good Job!
Regards,Yelena Varsha
-
We do a very light edit on most articles, compared to a much more intense edit for articles in the SQL Server Standard Magazine. Online is a little less formal and we let the authors have some leeway around grammar and spelling!
-
My apologies for "Simplicity Stake". Guess who wrote the article late at night on using a cheap keyboard?
-
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.
-
As a DBA my main concern is with apps developers who code things up with the assumption that they will have access to the SA password or similarly excessive access rights.
I would have thought that if you can add your own sections to a web.config file then you should be able to implement your own web.config reader to have a connection string decrypt method. The obvious problem is that the decryption key has to be stored somewhere.
-
The Data Access Application Block in the Enterprise Library makes use of the Configuration Application Block to store the connection information. The Configuration block can be used with the Cryptography block to encrypt the connection information without changing any code in the application.
This article mentions encrypting the connection information: http://msdn.microsoft.com/msdnmag/issues/05/07/DataPoints/
There might be a a tutorial on this on the tutorial site at http://channel9.msdn.com/wiki/default.aspx/Channel9.EnterpriseLibraryTutorials.
Problem solved
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
On the contrary Steve, config files are finally the perfect place to store connection strings since the .net 2.0 framework came out with "protected configuration".
This article will show you how to simplify encrypting your connection string in your config files (web AND app).
http://msdn2.microsoft.com/en-us/library/dtkwfdky.aspx
Hope this helps ease your mind! Before this came out, I shared your opinion about the plain text.
~DR
-
Won't it be nice when Kerberos is easier to set up. Then we can just do single sign-on and not worry about storing any credentials outside AD. If anyone knows of any good articles on how to set this up reliably I would love to know about it!
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
Thanks for the responses. We are still using 1.1 and an older version of the application blocks so once we move to 2.0 we will definately investigate the encryption. That might solve the trick.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply