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

"Mr Newbie" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

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" <davidbaxterbrowne no potted (E-Mail Removed)> wrote in
message news:%23o9mS%(E-Mail Removed)...
>
> "Mr Newbie" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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
>