Coffeehouse Thread

5 posts

Always use a DAL?

Back to Forum: Coffeehouse
  • User profile image
    Larsenal

    I have to admit that I haven't been so good about learning all the new .NET 2.0 stuff.  I came across this neat article: http://www.codeguru.com/columns/DotNet/article.php/c9783/ that shows how the new DbProviderFactory works.  I personally like this idea a lot.  Will this allow us to avoid a proper DAL for relatively small projects?

    When I'm working on small projects where I'm pretty confident that the Database Provider won't change, a lot of DatabaseProvider-specific code ends up getting semi-hardcoded into the app.  If it's a small project, I am sometimes too lazy to properly separate things into a DAL.

    Do you find yourselves doing this on small (usually personal) projects too or do you always try to follow best practices in keeping the DB implementation separate?

  • User profile image
    W3bbo

    I usually create a "DatabaseHandler" class and abstract everything through there.

    Not sure if that's "best practices" though.

  • User profile image
    gangstah

    I have a real disease when it comes to this.  If I don't seperate the DAL properly I get all grumpy and shakey.  I mean...there should be some common sense but I never bind a grid to a sqldatareader, never return datareaders to UI logic, etc.  Although 99% of my projects are SQL Server and will always be SQL Server I still can't seem to find the courage to mix the UI with DAL.  Stupid I know.

  • User profile image
    Tyler Brown

    W3bbo wrote:
    I usually create a "DatabaseHandler" class and abstract everything through there.

    Not sure if that's "best practices" though.

    This is exactly what I have done when I have interacted with a database. So far that's only been with PHP, but that will change Wink

  • User profile image
    Sabot

    W3bbo wrote:
    I usually create a "DatabaseHandler" class and abstract everything through there.

    Not sure if that's "best practices" though.


    <Action> Put Architecture Hat-On (yes it has mickey ears) </Action>

    You always, always, always, always saperate data layer access from business logic even if you don't physically saperate them in a different assembly or service etc.

    Why?

    Maintainability! Changes are you are going to have to go back to that code sooner or alter, or someone else is. Making further changes to the code will either/or increase the business logic or database code, which means the code will get further entwined, which leads to spagetti with sauce (usually leaking from frustated developers body where he/she is stabbing himself or you)

    The other reason is, reuse. whether this really ever happens is a debatable point, but 'the law of averages' comes into play here, if you have it, you can reuse it if you remember you have it. (Hey isn't that what UDDI is all about with SOA? Yep I believe it is) Oh yeah, mmmm, big picture must remember to look at that one now and again.

    ;o)

    -Dave

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.