Anatoly Lubarsky

I played a little bit with entlib 2.0 today. Good news is that DbCommandWrapper class is obsolete. Database class works now directly with System.Data.Common.DbCommand class. Instead of:

Database db = DatabaseFactory.CreateDatabase("MyDB");
string procName = "MyPROC";
DBCommandWrapper dbc = db.GetStoredProcCommandWrapper(procName);
dbc.AddInParameter("@myParam", DbType.String, myParam);

We now can write:

Database db = DatabaseFactory.CreateDatabase("MyDB");
string procName = "MyPROC";
DbCommand dbCommand = db.GetStoredProcCommand(procName);
db.AddInParameter(dbCommand, "@myParam", DbType.String, myParam);

What I don't like is the fact that you can not specify the size of the parameter inside AddInParameter in the normal way as you can do in AddOutParameter (the same behaviour exists in Entrperise Library 1.0). Because of this - DataAccess block passes the max size of the specified DbType and performance sucks.

Related Posts:

• Enterprise Library 2.0 extensions
• .NET 2.0: List<T>.Exists and anonymous method
• Enterprise Library for .NET Framework 2.0
• This site is running on ASP.NET 2.0 (2)
• .NET 2.0: List<T> is my hero
• New in .NET 2.0: ConfigurationManager.AppSettings Property
• .Net Framework 3.0: Business Layer on DLinq
• .Net Framework 2.0: Generic Collections
• Enterprise Library 2005: Event Handling Application Block
• .Net Framework 2.0: DAAB in Enterprise Library

Yep, and working with blobs is a pain ...

Surely you can just change the Entlib code to be how you want it and recompile? Isn't that the point of having the source code?

If you didn't you'd probably create your own wrapper classes similar to the Entlib anyway?

2 somebody:
Sure I can create my own wrapper class around SqlCommand class in this case instead of DataAccess application block.

Recompiling Entlib is the pain in the ass, imho. After the following release you should again change and recompile.