Application blocks is your best bet.
Here is why -
a) It is written by smart people, who have dealt with inexperience and
inexperienced.
b) It is written in a standard manner, and will probably work when we are
all living underwater coz the world is being ruled by ape men from mars.
c) It is written using the best practices.
d) It helps you not to reinvent the wheel. Why write, when you can steal?
(Hehe).
Lots more reasons.
Either way, you do want to segregate your data access layer into a stateless
layer that encapsulates all database native stuff .. and spews out business
data instead of database native stuff like SQL. .Try and make this
class/classes
a) Stateless
b) Supportable in Enterprise Services/MTS, so when you finally scale, you
could make these Queued or Objectpooled.
c) Independent of communication protocol i.e. for example - remoting support
should not be a part of this layer.
Read my forthcoming book on ADO.NET (Due to be released by apress in
November) (LOL). When you design the "data layer" for a project, you should
have a thorough understanding of what ADO.NET gives you, and why it gives
certain things in a disconnected world that were unecessary earlier. Also
topics like concurrency etc. are extremely important.
- Sahil Malik
Independent Consultant
You can reach me thru my blog at -
http://www.dotnetjunkies.com/weblog/sahilmalik/
jacobryce said:
Our group is new to .net and needs to decide on a good methodology for
dealing with data sources, data connections, etc...
I came across the data access application block but I'm wondering if it's
overkill. Any opinions about it or suggestions on other ways? Thanks!
