DataBase Centric Applications - Best Approach

[Mr Newbie]

I've just spent some considerable time putting together an application which
works pretty much OK. The issue I have around design is mainly concerned
with the Data Access layer.

Yes, we can pull data modify it etc, but the code required to do so is not
inconsequential , and the many functions one finds onself writing do mount
up.

All this is OK until you find you need to change a type or add or remove a
field, everything has to change and its a nightmare to have to retrofit your
code to remedy that.

So Im sitting here thinking that there must be a scalable flexible way to
approach the design to minimise this rework. Does anyone have any ideas,
URLS's etc that may be of help, or even a few words of advice.
Thanks Mr N

[David Browne]

"Mr Newbie" <he**@now.com > wrote in message
news:u8******** ******@TK2MSFTN GP11.phx.gbl...

I've just spent some considerable time putting together an application
which works pretty much OK. The issue I have around design is mainly
concerned with the Data Access layer.

Yes, we can pull data modify it etc, but the code required to do so is not
inconsequential , and the many functions one finds onself writing do mount
up.

All this is OK until you find you need to change a type or add or remove a
field, everything has to change and its a nightmare to have to retrofit
your code to remedy that.

So Im sitting here thinking that there must be a scalable flexible way to
approach the design to minimise this rework. Does anyone have any ideas,
URLS's etc that may be of help, or even a few words of advice.

Here are a few good options:

DataSets and the Visual Studio Designers, especially in VS2005, where
TableAdapters manage your CRUD commands as well as your Typed Datasets.

Custom DAL, with Command Wrappers and Entity Types, using codegen (eg
http://www.codesmithtools.com/) to generate allthe boilerplate code for you.
This is essentially what you're doing, just with the addition of a codegen
tool to automate it.

ORM solutions (http://search.msn.com/results.aspx?q=.net+orm&FORM=QBHP,
http://www.nhibernate.org). These move the action into the client tier and
handle the database plumbing behind the scenes.


David

[Mr Newbie]

I'll take a look at these options and see how they might be of help.

Thanks for your help.

--
Best Regards

The Inimitable Mr Newbie º¿º

"David Browne" <davidbaxterbro wne no potted me**@hotmail.co m> wrote in
message news:%2******** **********@TK2M SFTNGP10.phx.gb l...

"Mr Newbie" <he**@now.com > wrote in message
news:u8******** ******@TK2MSFTN GP11.phx.gbl...

I've just spent some considerable time putting together an application
which works pretty much OK. The issue I have around design is mainly
concerned with the Data Access layer.

Yes, we can pull data modify it etc, but the code required to do so is
not inconsequential , and the many functions one finds onself writing do
mount up.

All this is OK until you find you need to change a type or add or remove
a field, everything has to change and its a nightmare to have to retrofit
your code to remedy that.

So Im sitting here thinking that there must be a scalable flexible way to
approach the design to minimise this rework. Does anyone have any ideas,
URLS's etc that may be of help, or even a few words of advice.

Here are a few good options:

DataSets and the Visual Studio Designers, especially in VS2005, where
TableAdapters manage your CRUD commands as well as your Typed Datasets.

Custom DAL, with Command Wrappers and Entity Types, using codegen (eg
http://www.codesmithtools.com/) to generate allthe boilerplate code for
you. This is essentially what you're doing, just with the addition of a
codegen tool to automate it.

ORM solutions (http://search.msn.com/results.aspx?q=.net+orm&FORM=QBHP,
http://www.nhibernate.org). These move the action into the client tier
and handle the database plumbing behind the scenes.


David