Ent Library Application blocks

Discussion in 'ASP .Net' started by GaryDean, Aug 1, 2007.

  1. GaryDean

    GaryDean Guest

    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
    GaryDean, Aug 1, 2007
    #1
    1. Advertising

  2. 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" <> wrote in message
    news:ebc$...
    >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
    >
    >
    Kevin Spencer, Aug 1, 2007
    #2
    1. Advertising

  3. 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 (, 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.
    Walter Wang [MSFT], Aug 1, 2007
    #3
  4. GaryDean

    GaryDean Guest

    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" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:ebc$...
    >>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
    >>
    >>

    >
    >
    GaryDean, Aug 3, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arjen
    Replies:
    3
    Views:
    439
    Scott Allen
    Feb 27, 2005
  2. Mukesh
    Replies:
    4
    Views:
    525
    Walter Wang [MSFT]
    Oct 9, 2006
  3. Mukesh
    Replies:
    3
    Views:
    369
    Walter Wang [MSFT]
    Oct 11, 2006
  4. Mukesh
    Replies:
    3
    Views:
    320
    Walter Wang [MSFT]
    Oct 9, 2006
  5. matt
    Replies:
    1
    Views:
    259
    George Ogata
    Aug 6, 2004
Loading...

Share This Page