Enterprise Application Block

1
Enterprise Application Block

• Data Access Block

Sootanu Maitra
2
Why Enterprise Application Block ?
Axiom 1, of Scott's Axioms of ProgrammingWriting
more code leads to more bugs, which leads to a
longer development cycle, which leads to higher
costs. Therefore, a minimalistic approach should
be taken to writing code.
3
Enterprise Library v2.0

• Where did it come from?
• Origin was ICBAM ( Internet Component Based
  Architecture for Microsoft ) from Accenture
• ACA v1.0
• Built on Microsoft DNA ( Released early 2000 )
• 4 additional releases
• ACA.NET v1.0 is released simultaneously with .NET
  v1.0 ( Feb 2002 )
• ACA.NET 2.X ( Oct 2002 )
• ACA.NET 3.X ( Jan 2004 )
• EntLib v1.0 / ACA.NET 4.0 ( Nov 2004 )
• Microsoft Patterns and Practices partners with
  Avanade to release a subset of ACA.NET as EntLib
  1.0 replacing the Microsoft Application Blocks
• EntLib v2.0 / ACA.NET 4.1 ( Jan 2006 )
• Microsoft Patterns and Practices re-factors
  EntLib to take advantage of new features and
  enhancements in the .NET 2.0 framework

4
Enterprise Library v2.0

• Why do we need it?
• Microsoft .NET platform includes very broad,
  generic functionality
• This makes the platform suitable for a wide
  variety of application types and architectures
• However, specific customer segments have common
  needs at a higher level of abstraction. The
  platform does not always directly support these
  without a lot of manual work
• EntLib provides prescriptive guidance that links
  functionality together

5
Enterprise Library v2.0

• Graphical Configuration Tool
• Data Access Block
• Logging Access Block
• Exception Handling Block
• Cryptography Block
• Security Block
• Caching Block
• Built in Instrumentation

6
Data Access Block

• Enforces consistent development patterns
• One line access to common data access patterns
• Re-factored in 2.0 to leverage ADO.NET standard
  interfaces
• i.e. DbCommandWrapper was replaced by DbCommand
• Updated in 2.0 to work with any managed data
  provider
• Pre-instrumented!

7
Advantages of Data Access Block

• Maintain consistent data access practices, both
  in an application and across the enterprise.
• Reduce difficulties in changing the physical
  database target.
• Relieve developers from having to learn different
  
• programming models for different types of
  databases.
• Reduce the amount of code that needs to be
  rewritten when porting applications to different
  types of databases.
• Provide a single point of interception for data
  access monitoring and testing.
• Allow developers to abstract the data access code
  from the code related to business logic. This has
  the benefit of reducing and simplifying the code
  that usually exists in data access logic
  components.

8
Design Motives of DAAB

• The application block was designed to simplify
  the task of accessing data. Therefore, it
  required the following design decisions
• It should expose only a small number of methods
  that a developer would need to understand.
• It should encapsulate common housekeeping tasks.
• It should make it easy to handle parameters.
• It should provide good performance.
• It should be simple to create a database object.

9
Features of Data Access Block

• EntLib 1.0 focused solely on providing support
  to SQL Server. 2.0 supports other database
  vendors too.
• A generic abstract base class, named Database,
  has been designed that serves as the uniform
  interface for all types of databases.
• Code can be written against the base class'
  interface so it is agnostic as to the underlying
  data source.
• The ultimate data source that is used by an
  application is determined at runtime from
  configuration information.

10
Data Access Block Architecture
uses
11
Design of the Data Access Application Block
12
The Data Access Mechanism
Input and Output Parameters/Query
Config
constr
DB
Command Object
Fill
Dataset
13
Traditional Data Access Techniques

• Get a connection string and connection obj
• Create a Command Object
• Pass Conn to the Command Object
• Set CommandType as Stored Procedure
• Add Parameters
• Set Command Text sp name
• Declare DataAdapter, pass command obj constructor
• Declare Dataset
• Open the connection
• Make Adapter.Fill
• Make Datagrid.datasource Dataset
• Make Datagrid.databind
• Close the connection

14
Traditional Data Access Techniques

• Now imagine, this connection string is being
  fetched from a config. File
• This connection string is for a non-sql
  data-source
• The data access is for XML data
• It can also include insert ,update and deletes

Now imagine the complexity and the amount of code
that needs to be written and this happens every
now and then. Every alternate piece of code is
related to data access.
This is where the Data Access Application Block
steps in
15
Why not customized DALs ?

• Not completely tried and tested
• Not standardized
• Does not come with a sample application, decent
  documentation and detailed usage instructions
• Not generic
• Not applicable for Non sql data-sources

16
When to Use ADO.NET instead of DAAB ?

• The Data Access Application Block is a complement
  to ADO.NET it is not a replacement.
• The application block provides simplicity and
  convenience while helping developers use ADO.NET
  with best practices. If your application needs to
  retrieve data in specialized way, or if your code
  needs customization to take advantage of features
  specific to a particular database, using ADO.NET
  might better suit you.

17
Developing Applications Using the Data Access
Application Block

• Step1 - Entering Configuration Information
• To add the Data Access Application Block
• Start the Enterprise Library Configuration
  Console. To use the configuration console, click
  Start, point to All Programs, point to Microsoft
  patterns practices, point to Enterprise Library
  January 2006, and then click Enterprise Library
  Configuration.
• Click the New Application icon or the Open
  Existing Application icon.
• Right-click Application Configuration, point to
  New, and then click Data Access Application
  Block.

18
Developing Applications Using the Data Access
Application Block

• Step1 - Entering Configuration Information
• To configure the default database
• In the right pane, expand the DefaultDatabase
  property.
• Enter the connection string name for the
  DefaultDatabase property or select it from the
  dropdown box. The default connection string name
  is Connection String.
• (Optional) Set the Name property by typing a new
  name. The default name is Connection String.
• In the ProviderName property section, change the
  provider name if you want to. Enter the name of
  the provider or select it from the drop-down
  list. The default provider name is
  System.Data.SqlClient. The ProviderName property
  must be a provider name specified in a
  DBProviderFactory class.

Note This explains how to configure an instance
of the default database. This instance is used if
the application calls the DatabaseFactory.CreateDa
tabase method with no instance name.
19
Developing Applications Using the Data Access
Application Block

• Step2 - To prepare your application
• Add a reference to the Data Access Application
  Block assembly. In Visual Studio, right-click
  your project node in Solution Explorer, and then
  click Add References. Click the Browse tab, and
  then navigate to the location of the
  Microsoft.Practices.EnterpriseLibrary.Data.dll
  assembly. Select the assembly, and then click OK
  to add the reference.
• Following the same procedure, add references to
  the Enterprise Library Core assemblies,
  Microsoft.Practices.EnterpriseLibrary.Common.dll
  and Microsoft.Practices.ObjectBuilder.dll.
• To use elements from Data Access Application
  Block without fully qualifying the element
  reference, you can add the following using
  statement (C)

20
Developing Applications Using the Data Access
Application Block

• Step 3 - Creating the Database Object
• All data access methods are executed against a
  Database object. You can use the DatabaseFactory
  class to create a Database object. The specific
  type of Database object created by the factory is
  determined by the application configuration
  information.
• You can use the configuration console to specify
  a default database instance. The DatabaseFactory
  creates the database specified by the default
  instance when you call the CreateDatabase method
  without passing a database instance name. The
  following application code shows how to create a
  Database object for the default instance.

21
Developing Applications Using the Data Access
Application Block

• Step 4 - Creating a DbCommand Object
• The Data Access Application Block provides a
  consistent way to retrieve ADO.NET DbCommand
  objects.
• The method you call to retrieve a DbCommand
  object is determined by whether you want to
  execute inline SQL or call a stored procedure.
  The method that creates a DbCommand object for a
  stored procedure also provides parameter caching.
  
• All DbCommand objects are created using methods
  on the Database class. These methods are the
  following
• GetStoredProcCommand.
• GetSqlStringCommand.
• To create a DbCommand object for an inline SQL
  statement, use the GetSqlStringCommand method.

22
Developing Applications Using the Data Access
Application Block

• Step 5 - Managing Connections
• Database connections are a limited resource, and
  proper management of them is essential for
  scalable applications. It is good practice to
  keep connections open only as long as they are
  needed and to close them as soon as practical. By
  design, most of the Database class methods handle
  the opening and closing of connections to the
  database on each call.
• Therefore, the application code does not need
  to include code for managing connections.

23
Developing Applications Using the Data Access
Application Block

• Step 6 - Handling Exceptions
• The CreateDatabase method uses configuration
  information, which may result in
  configuration-related exceptions.
• The Database methods use both ADO.NET and the
  underlying database provider. Exceptions thrown
  by ADO.NET are caught by the Data Access
  Application Block for instrumentation purposes,
  and then they are rethrown.
• We can include a catch statement for a specific
  database provider exception such as SqlException.
  However, database providerspecific exception
  types are not portable across different
  providers.
• Use CommandBehavior.CloseConnection to call
  ExecuteReader. This closes the connection when
  the DataReader is closed. If you use
  ExecuteReader within a try block, you should add
  a finally statement and close the returned
  DataReader object.

24
Developing Applications Using the Data Access
Application Block

• Step 7 - Explicit Parameter Handling
• The Database class includes a variety of methods
  for passing parameters to stored procedures. This
  class also includes methods for setting and
  examining the values of those parameters. These
  methods are the following
• AddParameter. Passes a parameter (input or
  output) to a stored procedure.
• AddInParameter. Passes an input parameter to a
  stored procedure.
• AddOutParameter. Adds an output parameter to a
  stored procedure.
• GetParameterValue. Finds the value of the
  specified parameter.
• SetParameterValue. Sets the value of the
  specified parameter when you want to do multiple
  inserts using the same connection and command but
  with different parameter values.

25
Key Scenarios

• Using a DbDataReader to Retrieve Multiple Rows.
  This scenario illustrates how you can use the
  ExecuteReader method to retrieve multiple rows of
  data from a database for display in tabulated
  formwithout explicitly caching the data, using a
  DataSet object to manipulate it, or passing it to
  other components within your application. In
  other words, it illustrates how to display the
  results as quickly as possible.
• Using a DataSet to Retrieve Multiple Rows. This
  scenario illustrates how you can use the
  ExecuteDataSet method to pass data between the
  components and the tiers of a multi-tier
  application. The data consists of one or more
  data tables and, optionally, the relationships
  that link the tables together.
• Executing a Command and Accessing Output
  Parameters. This scenario illustrates how you can
  use the ExecuteNonQuery method to retrieve a
  single row that contains multiple column values.
• Executing a Command and Accessing a Single-Item
  Result. This scenario illustrates how you can use
  the ExecuteScalar method to perform a single-item
  lookup.
• Performing Multiple Updates Within a Transaction.
  This scenario illustrates how you can use the
  ExecuteNonQuery method from within a transaction
  to perform multiple operations against a
  database, where it is essential that either all
  operations succeed or none succeed.
• Using a DataSet to Update a Database. This
  scenario illustrates how, after changing a
  DataSet object, you can use the UpdateDataSet
  method to update the database and make your
  changes permanent.
• Retrieving Multiple Rows as XML. This scenario
  illustrates how you can use the ExecuteXmlReader
  method to retrieve data from a SQL Server and
  have that data returned in XML format.

26
Extending and Modifying the Data Access
Application Block

• The Enterprise Library can serve as the basis for
  a custom library. We can take advantage of the
  extensibility points incorporated in each
  application block and extend the application
  block by supplying new providers
• We can also modify the source code for the
  existing application blocks to incorporate new
  functionality
• We can even add new application blocks to the
  Enterprise Library

27
Guidelines for Extensibility

• An application block should provide a public API
  to expose the application block's functionality.
  The interface of the API should be independent of
  the internal implementation. Developers should
  not be required to understand the application
  block design or implementation to make effective
  use of its out-of-box functionality.
• Whenever possible, the API should apply across
  common scenarios for specific functionality
• An Enterprise Library application block should
  include instrumentation that enables developers,
  testers, and system administrators to monitor
  application block behavior and performance
• If one Enterprise Library application block
  requires another Enterprise Library application
  block to perform a task, then, where possible,
  the interdependent application blocks should be
  loosely coupled so that users can replace one of
  the application blocks with their own
  implementations

28
Guidelines for Extending and Customizing
Application Blocks

• An application block should provide extensibility
  points that let developers tailor the application
  block to suit their needs. The most common use of
  extensibility points is to allow developers to
  use their own providers
• Developers should be able to extend an
  application block without modifying its source
  code. To accomplish this, you should add
  extensibility points by including public base
  classes or interfaces.
• When defining the set of extensibility points,
  consider the effect on usability. A large number
  of extensibility points can make the application
  block complicated to use and difficult to
  configure.
• Some developers may be interested in customizing
  the code, which means that they will modify the
  source code instead of using the extension
  points. To support this effort, the application
  block design should provide the following
• It should follow object-oriented design
  principles whenever practical.
• It should use appropriate patterns.
• It should make efficient use of resources.
• It should adhere to security principles (for
  example, distrust of user input and principle of
  least privilege).

29
References

• Effective Use of Microsoft Enterprise Library
  Building Blocks for Creating Enterprise
  Applications and Services
• By Len Fenster
• http//msdn.microsoft.com/library/?url/library/en
  -us/dnpag2/html/EntLib2.asp