Removing datasets from our architecture...

Hello,

I was curious as to peoples thoughts on using tools such as
MyGeneration/CodeSmith to generate business objects as opposed to using
datasets? We currently use datasets, for various reasons I *suspect* we want
to move away from using them....

I guess my secondary question is will it be a complete rewrite to remove
datasets from the application? :( or is there an easy way to do it? (They
are HEAVILY used)

I wonder if we will be stuck with them forever more, or should I go through
the pain of changing *now*, somewhat early in the development process, (6
months) ...or should I just live with them...

Background Info
MsAccess Backend, Webservice consumed by a WinForms application all in .net

Thank you for any thoughts anyone has...
John

Re: Removing datasets from our architecture...

I use EntitySpaces, which are generated using MyGeneration

http://www.entityspaces.net/portal/Default.aspx

very powerful and you can put custom code into each object



John Sheppard wrote:
> Hello,
>
> I was curious as to peoples thoughts on using tools such as
> MyGeneration/CodeSmith to generate business objects as opposed to using
> datasets? We currently use datasets, for various reasons I *suspect* we
> want to move away from using them....
>
> I guess my secondary question is will it be a complete rewrite to remove
> datasets from the application? :( or is there an easy way to do it?
> (They are HEAVILY used)
>
> I wonder if we will be stuck with them forever more, or should I go
> through the pain of changing *now*, somewhat early in the development
> process, (6 months) ...or should I just live with them...
>
> Background Info
> MsAccess Backend, Webservice consumed by a WinForms application all in .net
>
> Thank you for any thoughts anyone has...
> John

Re: Removing datasets from our architecture...

John Sheppard wrote:
> Hello,
>
> I was curious as to peoples thoughts on using tools such as
> MyGeneration/CodeSmith to generate business objects as opposed to using
> datasets? We currently use datasets, for various reasons I *suspect* we
> want to move away from using them....

Perhaps you might like to look at 'real' OR mappers like
NHibernate/ActiveRecord or LLBLGen

> I guess my secondary question is will it be a complete rewrite to remove
> datasets from the application? :( or is there an easy way to do it?
> (They are HEAVILY used)

If you want to change working code, then you'll probably gain a lot from
a major refector or even a rewrite.
But if the code works, there probably isn't a reason to rewrite it
(unless you have nice unit tests to make major refactoring easy).

Alun Harford

Re: Removing datasets from our architecture...

Code generators are great, and highly recommended. However, it's not worth
ripping out working code unless you have a lot more DB code still needing
to be written. You should not make the change merely for the sake of making
the change. Only do so if the benefits in time/quality/maintenenance for
the remainder of the project outweigh the time & risk of making a major
change to functioning code.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


"John Sheppard" wrote in message
news:fh44sp021pi@news3.newsguy.com...
> Hello,
>
> I was curious as to peoples thoughts on using tools such as
> MyGeneration/CodeSmith to generate business objects as opposed to using
> datasets? We currently use datasets, for various reasons I *suspect* we
> want to move away from using them....
>
> I guess my secondary question is will it be a complete rewrite to remove
> datasets from the application? :( or is there an easy way to do it? (They
> are HEAVILY used)
>
> I wonder if we will be stuck with them forever more, or should I go
> through the pain of changing *now*, somewhat early in the development
> process, (6 months) ...or should I just live with them...
>
> Background Info
> MsAccess Backend, Webservice consumed by a WinForms application all in
> .net
>
> Thank you for any thoughts anyone has...
> John

Re: Removing datasets from our architecture...

Cool thanks, it looks interesting... I'll scope it out some...

"jay parzych" wrote in message
news:MVjZi.537$kl7.119@newsfe21.lga...
>I use EntitySpaces, which are generated using MyGeneration
>
> http://www.entityspaces.net/portal/Default.aspx
>
> very powerful and you can put custom code into each object
>
>
>
> John Sheppard wrote:
>> Hello,
>>
>> I was curious as to peoples thoughts on using tools such as
>> MyGeneration/CodeSmith to generate business objects as opposed to using
>> datasets? We currently use datasets, for various reasons I *suspect* we
>> want to move away from using them....
>>
>> I guess my secondary question is will it be a complete rewrite to remove
>> datasets from the application? :( or is there an easy way to do it? (They
>> are HEAVILY used)
>>
>> I wonder if we will be stuck with them forever more, or should I go
>> through the pain of changing *now*, somewhat early in the development
>> process, (6 months) ...or should I just live with them...
>>
>> Background Info
>> MsAccess Backend, Webservice consumed by a WinForms application all in
>> .net
>>
>> Thank you for any thoughts anyone has...
>> John

Re: Removing datasets from our architecture...

I suppose we cant really go OR mapping because we have an existing database
that is being migrated, so the relational model is all setup...

The code *works* but its messy as all hell, what concerns me most is
maintanance issues...I guess ideally itd be nicer to stay with datasets if I
can sort out keeping it tidy and maintanable (when i say done, its not
really done, just its been started on)...

Im relativly new at it all...what im concidering is a 1:1 table/view to
buisiness object...I realise there are reasons not to do that, but we dont
have time to do fullon UML stuff...

I personally think the thing needs a complete rewrite, but I have other
parties here saying neigh, and Im not experienced enough to argue
differently...


"Alun Harford" wrote in message
news:OAmTPN9IIHA.2064@TK2MSFTNGP06.phx.gbl...
> John Sheppard wrote:
>> Hello,
>>
>> I was curious as to peoples thoughts on using tools such as
>> MyGeneration/CodeSmith to generate business objects as opposed to using
>> datasets? We currently use datasets, for various reasons I *suspect* we
>> want to move away from using them....
>
> Perhaps you might like to look at 'real' OR mappers like
> NHibernate/ActiveRecord or LLBLGen
>
>> I guess my secondary question is will it be a complete rewrite to remove
>> datasets from the application? :( or is there an easy way to do it? (They
>> are HEAVILY used)
>
> If you want to change working code, then you'll probably gain a lot from a
> major refector or even a rewrite.
> But if the code works, there probably isn't a reason to rewrite it (unless
> you have nice unit tests to make major refactoring easy).
>
> Alun Harford

Re: Removing datasets from our architecture...

Yeah you are right,

I guess the existing code works, but its close to unmaintainable, so I
wonder weather now is the time to jump ship to proper business objects
instead of trying to hack around with datasets...

Our main conundrum is that we have an access database that is falling over
from too many users, its not very well designed, and we are in a hurry to
get it migrated.....

Thank you!
John

"Andrew Faust" wrote in message
news:730D729B-19DB-42B8-84A4-FA09BD1B1419@microsoft.com...
> Code generators are great, and highly recommended. However, it's not worth
> ripping out working code unless you have a lot more DB code still needing
> to be written. You should not make the change merely for the sake of
> making the change. Only do so if the benefits in
> time/quality/maintenenance for the remainder of the project outweigh the
> time & risk of making a major change to functioning code.
>
> --
> Andrew Faust
> andrew[at]andrewfaust.com
> http://www.andrewfaust.com
>
>
> "John Sheppard" wrote in message
> news:fh44sp021pi@news3.newsguy.com...
>> Hello,
>>
>> I was curious as to peoples thoughts on using tools such as
>> MyGeneration/CodeSmith to generate business objects as opposed to using
>> datasets? We currently use datasets, for various reasons I *suspect* we
>> want to move away from using them....
>>
>> I guess my secondary question is will it be a complete rewrite to remove
>> datasets from the application? :( or is there an easy way to do it? (They
>> are HEAVILY used)
>>
>> I wonder if we will be stuck with them forever more, or should I go
>> through the pain of changing *now*, somewhat early in the development
>> process, (6 months) ...or should I just live with them...
>>
>> Background Info
>> MsAccess Backend, Webservice consumed by a WinForms application all in
>> .net
>>
>> Thank you for any thoughts anyone has...
>> John
>

Re: Removing datasets from our architecture...

John Sheppard wrote:
> I suppose we cant really go OR mapping because we have an existing
> database that is being migrated, so the relational model is all setup...

IIRC LLBLGen can generate the classes straight from your existing
database, and NHibernate is also pretty painless.

> The code *works* but its messy as all hell, what concerns me most is
> maintanance issues...I guess ideally itd be nicer to stay with datasets
> if I can sort out keeping it tidy and maintanable (when i say done, its
> not really done, just its been started on)...
>
> Im relativly new at it all...what im concidering is a 1:1 table/view to
> buisiness object...I realise there are reasons not to do that, but we
> dont have time to do fullon UML stuff...
>
> I personally think the thing needs a complete rewrite, but I have other
> parties here saying neigh, and Im not experienced enough to argue
> differently...

Rewrites have a nasty tendency to kill products in large companies, or
kill the company in small companies.

Read up on what killed Netscape, before deciding on a rewrite.

If code can be refactored, you're probably better off that way.

Alun Harford

Re: Removing datasets from our architecture...

> but its close to unmaintainable,

If that's true it might be worth the cost to make a change. You're going to
need to do your own analysis of cost/time & benefit to decide that one.

> Our main conundrum is that we have an access database that is falling
> over from too many users

By all means switch to something better. You don't necessarily need to
completely overhaul all your code to make this change, though. Depending on
how you built your app you may need to merely create a new database and
change the connection string you are using to connect to the DB. ADO.Net is
great about being database independent. So long as you aren't using
database specific functionality you can often change DB types simply by
changing the connection parameters and the actual type of DbConnection,
DbCommand & DbDataAdapter objects created.

You should certainly take that in to consideration on your decision.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com


"John Sheppard" wrote in message
news:fh6sdq02biq@news4.newsguy.com...
> Yeah you are right,
>
> I guess the existing code works, but its close to unmaintainable, so I
> wonder weather now is the time to jump ship to proper business objects
> instead of trying to hack around with datasets...
>
> Our main conundrum is that we have an access database that is falling
> over from too many users, its not very well designed, and we are in a
> hurry to get it migrated.....
>
> Thank you!
> John
>
> "Andrew Faust" wrote in message
> news:730D729B-19DB-42B8-84A4-FA09BD1B1419@microsoft.com...
>> Code generators are great, and highly recommended. However, it's not
>> worth ripping out working code unless you have a lot more DB code still
>> needing to be written. You should not make the change merely for the
>> sake of making the change. Only do so if the benefits in
>> time/quality/maintenenance for the remainder of the project outweigh the
>> time & risk of making a major change to functioning code.
>>
>> --
>> Andrew Faust
>> andrew[at]andrewfaust.com
>> http://www.andrewfaust.com
>>
>>
>> "John Sheppard" wrote in message
>> news:fh44sp021pi@news3.newsguy.com...
>>> Hello,
>>>
>>> I was curious as to peoples thoughts on using tools such as
>>> MyGeneration/CodeSmith to generate business objects as opposed to using
>>> datasets? We currently use datasets, for various reasons I *suspect* we
>>> want to move away from using them....
>>>
>>> I guess my secondary question is will it be a complete rewrite to
>>> remove datasets from the application? :( or is there an easy way to do
>>> it? (They are HEAVILY used)
>>>
>>> I wonder if we will be stuck with them forever more, or should I go
>>> through the pain of changing *now*, somewhat early in the development
>>> process, (6 months) ...or should I just live with them...
>>>
>>> Background Info
>>> MsAccess Backend, Webservice consumed by a WinForms application all in
>>> .net
>>>
>>> Thank you for any thoughts anyone has...
>>> John
>>
>

RE: Removing datasets from our architecture...

I would leave well alone and consider using the OR mapper in VS2008 which
generates classes that are immediately usable with LINQ as and when you do a
major rewrite.

Guy

"John Sheppard" wrote:

> Hello,
>
> I was curious as to peoples thoughts on using tools such as
> MyGeneration/CodeSmith to generate business objects as opposed to using
> datasets? We currently use datasets, for various reasons I *suspect* we want
> to move away from using them....
>
> I guess my secondary question is will it be a complete rewrite to remove
> datasets from the application? :( or is there an easy way to do it? (They
> are HEAVILY used)
>
> I wonder if we will be stuck with them forever more, or should I go through
> the pain of changing *now*, somewhat early in the development process, (6
> months) ...or should I just live with them...
>
> Background Info
> MsAccess Backend, Webservice consumed by a WinForms application all in .net
>
> Thank you for any thoughts anyone has...
> John
>
>

Re: Removing datasets from our architecture...

I would suggest this route:

A. Do it. Custom Business Objects and Custom Collections are alot more
maintainable than DataSets.
B. Pick one entity you would like to change. And convert it ...manually in
your code.
C. After you get a feel for it, then consider using CodeSmith templates.
You may have to create your own template.

The existing CodeSmith templates might be overkill for what you are wanting.
Or rather, after you get the result code, you may be overwhelmed at first.
Its better to get a feeling for Custom Business Objects and Collections
before making that jump.

(on c above) you can create your own template to match your needs. My
company has a code generation template, that maps out our namespaces from
the getgo.
Aka, we can copy and paste the code exactly to our liking because we figured
out how to make the template.


The one place I still use (strong) datasets is reporting. It not worth the
drama (to me) of using Custom Business objects for just reporting needs.


Look at this blog entry:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!1 39.entry

and you can also find the 2.0 version as well, but start with the 1.1
version.

There is a MS article I reference as well ("bird's eye view") you should
read. It discusses alot of the different options.

DataSets are good for RAPID development , but for maintainable code that
needs to grow/extend, custom object and collections are worth the effort.

.....

At some point you'll have to make the jump. Consider Unit Tests where you
can compare the old versus new code as well.

When you make the jump, don't try to put in new features at the same time.
Try to keep it the same, get comfortable with the switch, and then integrate
new features.

This is one opinion of many as well.



"John Sheppard" wrote in message
news:fh44sp021pi@news3.newsguy.com...
> Hello,
>
> I was curious as to peoples thoughts on using tools such as
> MyGeneration/CodeSmith to generate business objects as opposed to using
> datasets? We currently use datasets, for various reasons I *suspect* we
> want to move away from using them....
>
> I guess my secondary question is will it be a complete rewrite to remove
> datasets from the application? :( or is there an easy way to do it? (They
> are HEAVILY used)
>
> I wonder if we will be stuck with them forever more, or should I go
> through the pain of changing *now*, somewhat early in the development
> process, (6 months) ...or should I just live with them...
>
> Background Info
> MsAccess Backend, Webservice consumed by a WinForms application all in
> .net
>
> Thank you for any thoughts anyone has...
> John