Forum Moderators: open
Mostly we have used the data application block because that is the easiest to implement. For instance, You can simply with a couple of lines of code access your database without having to worry about managing your connections, command objects, etc. It does that for you.
For instance, returning a dataset is as easy as the following:
dim dataBase as Microsoft.Practices.EnterpriseLibrary.Data.Database = Database.CreateDatabase()
dim myDataSet as dataset = database.ExecuteDataSet("mySPROC", inputParam1, inputParam2, inputParam3)
That is all there is to it. You don't have to create connection objects, open or close them and you didn't even need a data adapter to fill the dataset.
Of course, you still have all the control over the objects that you want to use, as there are times that you need to create connection objects or command objects when using things such as transactions or output parameters.
There are other great application blocks as well such as the caching provider (if you are using a non-ASP.Net application).
The current release 3.0 is the best so far as the install package was better than the previous and there is documenation integrated into the Visual Studio help if you are using VS.Net. There is also the web.config editor that helps add the correct settings to your web.config to be able to use these providers.
[edited by: TheNige at 8:43 pm (utc) on April 30, 2007]
I would say it takes only about 1/3 of the time to write your data access code compared to before when using the enterprise library. Simply because you only need the few lines of code to do the work.
You can also take into account that it should help you avoid mistakes such as not closing connections, etc. and can help a team be more consistant in the way that they perform the data access.
[edited by: TheNige at 9:51 pm (utc) on May 1, 2007]
I was just thinking how many times I have thought of a new DAL method; repeating same things SQLConntection, SQLCommand,... then you make a mistake add the wrong SQlDataType! 2 hours gone easily.
I sorta drifted to WCSF; which seems to include the Enterprise Lib and add some more blocks on top of it; however i think its better to start from the Enterprise Lib to begin with then migrate to software factories.