Datasets or object model for "standard app"?

[Burt]

I'm working on a Windows app that pulls data from SQL Server, displays
it on various forms and grids, and allows the user to update, insert,
delete data. Some but not much business logic, just validation and and
some processing, like allowing the user to import data into the db
from upstream.

Trying to decide between datasets, and creating an object model
layer.

Articles like http://msdn.microsoft.com/msdnmag/is...e/default.aspx
say datasets are best only for "prototyping", but another group at my
company is using them for a fairly complex app.

Does anyone have thoughts on this, or experiences to share?

Thanks,

Burt

[Nicholas Paldino [.NET/C# MVP]]

Burt,

Well, that's the thing, there is no solution for a "standard" app. Some
people don't like all the overhead associated with DataSets, while others
find that overhead essential to what they do.

What you really have to do is look at your needs, and also make some
estimates about what each approach is going to give for you, and the
complications that are going to arise from using each approach. Once you
start asking those questions, it should be pretty obvious what you should
do.

You also have to think about the maintainability of the app. If you
come up with some custom object model, you will most likely have to write
much more in your data layer, figure out the protocol you want to use in
getting values out of your business object and how you persist them to the
database, etc, etc.

Personally, I like data sets. I like that they mirror the relational
model, because that's really what I am working with. I like the idea of the
data container separate from its operations (that spits in the face of OO,
but in a transactional environment, it makes much more sense).

But that's just me and the needs I have for my programs. You really
have to put the work in to figure out what is right for you.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Burt" <bu*******@yahoo.comwrote in message
news:11**********************@b58g2000hsg.googlegr oups.com...

I'm working on a Windows app that pulls data from SQL Server, displays
it on various forms and grids, and allows the user to update, insert,
delete data. Some but not much business logic, just validation and and
some processing, like allowing the user to import data into the db
from upstream.

Trying to decide between datasets, and creating an object model
layer.

Articles like
http://msdn.microsoft.com/msdnmag/is...e/default.aspx
say datasets are best only for "prototyping", but another group at my
company is using them for a fairly complex app.

Does anyone have thoughts on this, or experiences to share?

Thanks,

Burt

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

It really depends on how sophisticated you want to get with your application,
and whether you want to develop some sort of entity-object framework that
you'll re-use across different applications.

I've developed plenty of applications that use only the ADO.NET objects like
DataSet, DataReader, DataAdapter, bound directly to controls in the UI.

I've also used more sophisticated entity / DAL frameworks such as the
NetTiers framework that can be generated with CodeSmith.

Hope that helps,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Burt" wrote:

I'm working on a Windows app that pulls data from SQL Server, displays
it on various forms and grids, and allows the user to update, insert,
delete data. Some but not much business logic, just validation and and
some processing, like allowing the user to import data into the db
from upstream.

Trying to decide between datasets, and creating an object model
layer.

Articles like http://msdn.microsoft.com/msdnmag/is...e/default.aspx
say datasets are best only for "prototyping", but another group at my
company is using them for a fairly complex app.

Does anyone have thoughts on this, or experiences to share?

Thanks,

Burt

[sloan]

If it is something you're going to be maintaining for a while, then I would
side with Custom Business Objects.

The cost of creating the custom business objects is minimal compared to the
increased maintenence benefits you get.

Its hard to explain, its just a gut truth I have now.

There isn't anything wrong with (strong typed) datasets as your "poor mans
business objects", but as I said, the moment you hit something where a BO
would make life so much easier, you'd always wished you put in the time up
front.

With 2.0 and Generics, the collection type stuff, life is much easier.
The one place where I still write strong datasets is Reports. I find the
tweaking I can do with strong datasets for reporting easier.

6/5/2006
Custom Objects and Tiered Development II // 2.0
http://sholliday.spaces.live.com/blog/


"Burt" <bu*******@yahoo.comwrote in message
news:11**********************@b58g2000hsg.googlegr oups.com...

I'm working on a Windows app that pulls data from SQL Server, displays
it on various forms and grids, and allows the user to update, insert,
delete data. Some but not much business logic, just validation and and
some processing, like allowing the user to import data into the db
from upstream.

Trying to decide between datasets, and creating an object model
layer.

Articles like

http://msdn.microsoft.com/msdnmag/is...e/default.aspx

say datasets are best only for "prototyping", but another group at my
company is using them for a fairly complex app.

Does anyone have thoughts on this, or experiences to share?

Thanks,

Burt

[Burt]

Thanks all. I guess there's no right answer. Sometimes I think MS just
gives too many design choices and maybe or maybe not useful add ons
(like the enterprise library).

Burt