Merits of using a DAL

  • Thread starter Thread starter Paul Aspinall
  • Start date Start date
P

Paul Aspinall

In an environment such as VS which allows great integration of the Database
design components visually in the IDE, and given that a target app is will
be deployed on a single machine (ie. not n-tier or client server), I'm
debating the concept of using a DAL.

Other than logical design, I cannot see a benefit of using it.

Can anyone offer any opinions?

Thanks
 
If your program will be required to migrate to some other database such as
if you start out with access and think that you may move to SQL later or if
the code is for some project that may require future expansion, re-write for
Avalon, addition of a web-interface then use the DAL idea.

If not then don't bother to complicate your life any more than you need to.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
Paul said:
In an environment such as VS which allows great integration of the
Database design components visually in the IDE, and given that a
target app is will be deployed on a single machine (ie. not n-tier or
client server), I'm debating the concept of using a DAL.

Other than logical design, I cannot see a benefit of using it.

Can anyone offer any opinions?
Click to expand...

Well, this is a typical coder's approach -- go with the tools and be
done with it. But unfortunately, once you wear a tester's hat, or an
architect's hat, things aren't that easy anymore.

First, you cannot unit test your application in a meaningful way,
because you're unit is the entire application. There's no way to "mock"
or "stub" the DAL without a proper DAL. This also means that there's no
easy way to swap out implementations (e.g. Oracle vs. SQL Server), if
that ever becomes a requirement -- there's no abstraction layer
protecting the rest of your application from data access implementation
details.

Second, unless you're data access code is utterly trivial, I'm sure
that you'll find repeating similar data access code all over the place.
It doesn't matter whether it's handwritten or generated by tools. It
violates one of the most fundamental design principles: Don't repeat
yourself. And it quickly becomes a maintenance nightmare.

If you're asking as a hobbyist though, things are different -- do
whatever you're most comfortable with ;-)

Cheers,
 
Back
Top