The Microsoft Patterns and Practices group has developed several application blocks to perform functions ranging from caching to data access. The goal is to create code libraries that most enterprise solutions require. This most recent incarnation of the application blocks includes updated versions of many of the older blocks as well as some new ones.
This will complete the Enterprise Library installation by creating its specific performance counters. Then you will be able to view the Enterprise Library performance counters via PerfMon. Hopefully, future releases of Enterprise Library will include this step in the installation.
All of the Enterprise Library blocks use the Configuration Application Block as well as a common library. The blocks integrate with each other easily but they are also built to stand independently. For example, Enterprise Library's Logging and Instrumentation Application Block can log messages to an event log or to a file.
However, it can also log messages to a database by using the DAAB. The seven blocks are:. At a minimum, these seven Enterprise Library blocks rely on the Configuration Application Block as shown in Figure 1 and the common library, which contains a limited but commonly required set of functionality.
For example, it exposes a bit of cryptography so that the Configuration Application Block can optionally encrypt its entries without having to reference the entire Cryptography Application Block which references the Configuration Application Block, as do all Enterprise Library blocks. The beauty of the Enterprise Library blocks is that you can choose which blocks to use without having to develop them from scratch.
It is a best practice to use a DAL in an enterprise solution. Developing and testing one that abstracts ADO. NET and specific database provider objects, and which handles common data practices, takes time. The DAABs save you that time. Far too often I see applications that have problems with connection state and connection pooling as well as inconsistencies in the way connection strings are stored.
While the connection object may have a simple purpose connect to a data provider , it is often the source of scalability and resource problems. As shown in Figure 2 , the Enterprise Library DAAB stores connection strings in its own config file, which can be edited using the Enterprise Library Configuration Tool, making editing and maintaining the configuration settings easier than editing an XML configuration file by hand.
The DAAB also helps manage connection state for you. For example, if you want to fill a DataSet or insert some rows by executing a stored procedure, the DAAB automatically opens and closes the connection when needed. It uses the open late, close early approach so that connection pooling is maximized. Of course, you could write this code yourself, but it is easy to forget to close the connection. This code leaves the connection open after the ExecuteReader method executes so the resulting IDataReader object can still access the data:.
This returns an IDataReader object. The DAAB keeps the connection open as required. However, if you replaced the last line of code with the following, the DAAB would have opened and closed the connection for you:.
The configuration tool that comes with Enterprise Library provides an easy way to adjust and validate database settings for the DAAB.
By doing so, the information can be modified without having to recompile the application. Then navigate to and select the Web. The Configuration Application Block is used to help determine how to store and transform the other Enterprise Library blocks' config files. This also causes XML to be added to the Web. This file can store database connection string information for multiple connections. The Enterprise Library Config Tool automatically creates entries for connection strings, database instances, and database types.
If you want to use Oracle, however, you can add a new entry here and point it to the Oracle data provider. The dataConfiguration. After you create the new database type by right-clicking on Database Types and selecting New Database Type, you can select the Oracle data provider by clicking on the ellipses on the right side of the TypeName field as shown in Figure 3.
Or, you can add a different data provider by clicking on the Load an Assembly button. The SqlHelperParameterCache class is used in conjunction with the SqlHelper class to support the caching of SqlParameters, thus allowing you to reuse parameters without having to recreate them every time you need to run an SQL command. This parameter cache class uses a hash table to store parameter caches based on connection string and command text. You can set up a parameter cache in one of two ways: you can specify an array of SqlParameters yourself or you can specify a stored procedure and connection string, and it will build an array of SqlParameter objects using the SqlCommandBuilder class.
To retrieve the SqlParameter array just use the same connection string and command text you used to store the array to retrieve it. Table 3 describes the methods available for the SqlHelperParameterCache class. There are some important things you should know about when using this class. First, the GetSpParameterSet will only work with stored procedures.
Second, in order to retrieve the SqlParameter array the connection string must be syntactically and semantically correct, capitalization and all. Finally, remember that whenever you retrieve a SqlParameter array it is actually a clone of what is in the cache.
You can use this to your advantage by presetting SqlParameter values and storing those preset SqlParameter objects in the cache. One last thing to note is that if you use the GetSpParameterSet more than one time for a particular connection string and command string, the method will try to locate the SqlParameters in cache first before attempting to utilize the SqlCommandBuilder class to determine the list of parameters from the stored procedure.
If the GetSpParameterSet has to retrieve the parameters via the SqlCommandBuilder class, it will store them into the cache so that they can be used again later. Unfortunately, very rarely does one size fit all and the Data Access Application Block is no exception. It will handle most of what you need but you still may have to do some data access code by hand. For example, if you know your query may take more than 15 seconds to run, you probably don't want to use the SqlHelper class.
You cannot specify a command timeout so you are stuck with the SqlCommand's default of 20 seconds. Now of course since you have the source code there is nothing to stop you from overloading the existing methods and including a timeout parameter, but if there is to be a version 3.
Another area that you may have to get around is that since the SqlHelperParameterCache returns a set of SqlParameters as an array, there currently is no way to access the parameters by name, only by indexer. However, Listing 1 demonstrates a few lines of code you can use to get around that minor issue as well. Listing 2 illustrates how to use the Data Access Application Blocks. I created a string variable and set it to what my SQL command text will be. Next I set up the SqlParameter objects so I can pass some parameters to the stored procedure.
I simply pass in the Sqlcommand string and the SqlConnectionString via the conn. ConnectionString property. As I mentioned before, this method will attempt to find an array of SqlParameter objects for the given command and connection string, clone that array, and return the cloned SqlParameter array. Otherwise it will use the SqlCommandBuilder to retrieve the parameters from the database, cache the SqlParameters , clone the SqlParameter array, and return the cloned array.
Next I need to specify the values for my cloned copy of the SqlParameter array. This can pose a problem if the order of the parameters in the stored procedure changes. You'll have to live with this limitation unless you create a method for retrieving SqlParameter objects by name like in Listing 1. Finally I call the ExecuteDataSet method with the connection object, command type, command string, and SqlParameter array. Well, at least not directly. Remember that the method overloads that take an array of objects use the SqlHelperParameterCache behind the scenes to figure out the details for each SQL parameter.
The same rule about the order of the parameters in the stored procedures applies here. If the order in the stored procedure changes then you need to modify your code to match that order. Otherwise your procedure will be called with incorrect parameters resulting in an exception or garbage data being passed to your procedure.
Another thing to remember is that this particular overload only works with input SqlParameters, so you cannot retrieve output parameters. And you cannot pass in optional parameters.
Finally, I want to point out that I did not pass the values as an array. I use the C params keyword for the object array, allowing me to specify my values by simply listing them out. The VB. NET equivalent of this is the ParamArray keyword.
Next I created a string array of table names that the FillDataset method uses to map the resultset s returned by the SQLcommand to specific table names. This is really useful with typed DataSets to fill the typed DataTables.
As you can see, using this specific overload can result in a lot less coding, especially when you need to pass in a lot of parameters to an SQL Command. The Data Access Application Block can save a lot of time by allowing you to specify a few parameters and presto , you're done.
However, with simplification comes reduced flexibility and control. NET Framework 3. NET Framework 4. Is the issue solved? I am marking Ishan's reply as answer, if you have any concern with it, please feel free to unmark it and let us know. Ask a question. Quick access. Search related threads. Remove From My Forums. Answered by:. Archived Forums.
0コメント