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?
-
Follow
Oops, something didn't work.
Sign In to be begin to follow this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.Getting "follow" information
Start following this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.Removing your "follow"
Setting up your "follow"
Did you know you can
sign up for email notifications?
-
Larsenal
ready to give an answer
-
W3bbo
Work hard; increase production; prevent accidents, and be happy.
I usually create a "DatabaseHandler" class and abstract everything through there.
Not sure if that's "best practices" though. -
gangstah
"Am I on crazy pills?!?"
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.
-
Tyler Brown
Bullets change governments far surer than votes.
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
-
Sabot
My name is Dave Oliver. I'm a CTO
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
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.