Removing datasets from our architecture...

  • Thread starter Thread starter John Sheppard
  • Start date Start date
J

John Sheppard

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
 
John said:
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....
Click to expand...

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)
Click to expand...

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
 
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.
 
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...
 
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 said:
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 said:
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
Click to expand...
Click to expand...
 
John said:
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...
Click to expand...

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...
Click to expand...

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
 
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
Click to expand...

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 said:
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 said:
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 said:
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
Click to expand...
Click to expand...
Click to expand...
 
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
 
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!139.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.
 
Back
Top