Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Ent Library Application blocks

Reply
Thread Tools

Ent Library Application blocks

 
 
GaryDean
Guest
Posts: n/a
 
      08-01-2007
I have just been through the docs on the Data Access Application blocks and
it seems that they complicate things more than make things simple. To me it
seems that there is nothing more simple and straight forward than writing
simple stored procedures and executing them from .net code using easy to
understand connection strings.

I'm looking for opinions here from those that have used these tools. Am I
missing something?

--
Regards,
Gary Blakely


 
Reply With Quote
 
 
 
 
Kevin Spencer
Guest
Posts: n/a
 
      08-01-2007
Hi Gary,

Whether you're missing something or not is really determined by what your
needs are as a developer. In my own experience over a dozen years, I have
discovered that my scenarios have changed quite frequently, and I have
needed different functionality from databases from one project to another.
If you work on and maintain only one project, and the data requirements of
that one project are well-defined and unlikely to change, Data Access
Application Blocks might be more than you need. But if you have changing
requirements over a long period of time, and a changing set of team members
over time, they make good sense.

The idea of Data Access Application Blocks is derived from the same process
that gave rise to assembler, high-level programming languages, functions,
structures, and object-oriented programming. That is, certain types of
operations require the same or similar sequences of instructions and/or data
to be performed. So, rather than writing redundant code with many possible
points of failure, similar types of operations are combined and encapsulated
for re-use. As my Uncle Chutney sez, "Big things are made up of lots of
little things." If you enjoy typing the same thing over and over again, and
having more code to maintain, you certainly don't need any of these things.
OTOH, if you want to have a smaller code base to work with, less code to
debug and maintain, and fewer points of failure, encapsulation of common
functionality is the best way to go.

For example, as you've already mentioned, most database operations require a
couple of common things: A Connection, A Command, and a Container for any
results. Sometimes the Container is unnecessary, such as when performing
INSERT or UPDATE operations, but at the very least you want to have some
kind of return value to indicate status, success, or failure.

Of course, there are many different sorts of databases and other sources of
stored data. This means that these objects must be adaptable to different
database and data source types. But they do have a number of things in
common. So, the .Net Platform has the System.Data namespace which contains a
number of base classes that can be derived from to create
data-source-specific classes.

Still, within a given set of database parameters, to perform an operation of
some kind, you're likely to do at least the following operations for each:

1. Open a Connection
2. Create a Command
3. Execute the Command
4. Close the Connection

Now, that's 4 operations common to all database operations. The details
vary, but the basics remain the same. Now, why rewrite the code that does
these things each time you perform a database operation? Why not encapsulate
them into a single operation, or perhaps 2?

Obviously, if doable, that is a desirable scenario. For one thing, rather
than having 4 X (however many times your code needs to work with a database)
operations to debug in your code, you only have 4 X (1 Method call) to debug
and maintain. One point of failure, and one Method to maintain.

Now, the complexity arises out of those details that differ from one
database operation to another. The Connection String, for example, may
differ. The type of Command may differ. The result may or may not include
data. And so on. That is why the DAAB are designed as they are. There are
lower-level encapsulations of commonly-used items like Connections, and
higher-level implementations of combinations to handle recurring common
scenarios.

Of course, you may not need something quite as all-encompassing as the
Microsoft Data Access Application Blocks. You may want to implement
something more specific and light-wieght for your own needs. And the .Net
platform has all the pieces you need to do this. For example, my projects
almost all use SQL Server. So, I can create (and have created) similar,
simplified Data Access Application Blocks of my own for my sorts of
projects.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

"GaryDean" <(E-Mail Removed)> wrote in message
news:ebc$(E-Mail Removed)...
>I have just been through the docs on the Data Access Application blocks and
>it seems that they complicate things more than make things simple. To me
>it seems that there is nothing more simple and straight forward than
>writing simple stored procedures and executing them from .net code using
>easy to understand connection strings.
>
> I'm looking for opinions here from those that have used these tools. Am I
> missing something?
>
> --
> Regards,
> Gary Blakely
>
>



 
Reply With Quote
 
 
 
 
Walter Wang [MSFT]
Guest
Posts: n/a
 
      08-01-2007
Hi Gary,

Please check out following article for an overview of the benefits of DAAB:

#ASP.NET.4GuysFromRolla.com: Examining the Data Access Application Block
http://aspnet.4guysfromrolla.com/articles/070203-1.aspx


Regards,
Walter Wang ((E-Mail Removed), remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 
Reply With Quote
 
GaryDean
Guest
Posts: n/a
 
      08-03-2007
After spending a while longer with DAAB I don't see any advantage over what
I have been doing. But I now realize that, over the past year or so, I have
evolved my own DAAB. I like mine better.

thanks for your input. The other ABs might be valuable.
--
Regards,
Gary Blakely
Dean Blakely & Associates
www.deanblakely.com

"Kevin Spencer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Gary,
>
> Whether you're missing something or not is really determined by what your
> needs are as a developer. In my own experience over a dozen years, I have
> discovered that my scenarios have changed quite frequently, and I have
> needed different functionality from databases from one project to another.
> If you work on and maintain only one project, and the data requirements of
> that one project are well-defined and unlikely to change, Data Access
> Application Blocks might be more than you need. But if you have changing
> requirements over a long period of time, and a changing set of team
> members over time, they make good sense.
>
> The idea of Data Access Application Blocks is derived from the same
> process that gave rise to assembler, high-level programming languages,
> functions, structures, and object-oriented programming. That is, certain
> types of operations require the same or similar sequences of instructions
> and/or data to be performed. So, rather than writing redundant code with
> many possible points of failure, similar types of operations are combined
> and encapsulated for re-use. As my Uncle Chutney sez, "Big things are made
> up of lots of little things." If you enjoy typing the same thing over and
> over again, and having more code to maintain, you certainly don't need any
> of these things. OTOH, if you want to have a smaller code base to work
> with, less code to debug and maintain, and fewer points of failure,
> encapsulation of common functionality is the best way to go.
>
> For example, as you've already mentioned, most database operations require
> a couple of common things: A Connection, A Command, and a Container for
> any results. Sometimes the Container is unnecessary, such as when
> performing INSERT or UPDATE operations, but at the very least you want to
> have some kind of return value to indicate status, success, or failure.
>
> Of course, there are many different sorts of databases and other sources
> of stored data. This means that these objects must be adaptable to
> different database and data source types. But they do have a number of
> things in common. So, the .Net Platform has the System.Data namespace
> which contains a number of base classes that can be derived from to create
> data-source-specific classes.
>
> Still, within a given set of database parameters, to perform an operation
> of some kind, you're likely to do at least the following operations for
> each:
>
> 1. Open a Connection
> 2. Create a Command
> 3. Execute the Command
> 4. Close the Connection
>
> Now, that's 4 operations common to all database operations. The details
> vary, but the basics remain the same. Now, why rewrite the code that does
> these things each time you perform a database operation? Why not
> encapsulate them into a single operation, or perhaps 2?
>
> Obviously, if doable, that is a desirable scenario. For one thing, rather
> than having 4 X (however many times your code needs to work with a
> database) operations to debug in your code, you only have 4 X (1 Method
> call) to debug and maintain. One point of failure, and one Method to
> maintain.
>
> Now, the complexity arises out of those details that differ from one
> database operation to another. The Connection String, for example, may
> differ. The type of Command may differ. The result may or may not include
> data. And so on. That is why the DAAB are designed as they are. There are
> lower-level encapsulations of commonly-used items like Connections, and
> higher-level implementations of combinations to handle recurring common
> scenarios.
>
> Of course, you may not need something quite as all-encompassing as the
> Microsoft Data Access Application Blocks. You may want to implement
> something more specific and light-wieght for your own needs. And the .Net
> platform has all the pieces you need to do this. For example, my projects
> almost all use SQL Server. So, I can create (and have created) similar,
> simplified Data Access Application Blocks of my own for my sorts of
> projects.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
>
> Printing Components, Email Components,
> FTP Client Classes, Enhanced Data Controls, much more.
> DSI PrintManager, Miradyne Component Libraries:
> http://www.miradyne.net
>
> "GaryDean" <(E-Mail Removed)> wrote in message
> news:ebc$(E-Mail Removed)...
>>I have just been through the docs on the Data Access Application blocks
>>and it seems that they complicate things more than make things simple. To
>>me it seems that there is nothing more simple and straight forward than
>>writing simple stored procedures and executing them from .net code using
>>easy to understand connection strings.
>>
>> I'm looking for opinions here from those that have used these tools. Am
>> I missing something?
>>
>> --
>> Regards,
>> Gary Blakely
>>
>>

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to use microsoft application blocks ent lib june 2005 Mukesh ASP .Net 3 10-11-2006 09:35 AM
how to use microsoft application blocks ent lib june 2005 Mukesh ASP .Net 4 10-09-2006 02:52 AM
still probs ::: how to use microsoft application blocks ent libjune 2005 Mukesh ASP .Net 3 10-09-2006 02:49 AM
procs/blocks - blocks with procs, blocks with blocks? matt Ruby 1 08-06-2004 01:33 AM



Advertisments