I have an XML file I've created in another application that contains
information on files, forms, and job header. My plan is, in my new
"consumer" app, to read in this data and work with it, ultimately
producing labels for shipping, etc.

My planned approach is to construct a Dataset with 3 DataTables from this
data: One table for job header; one table for form info; and one table
for specific records. Then I want to set up one-to-many relations from
the top, down.

It's probably the SQL Server programmer in me that I'm taking this
approach, am I overthinking it? Should I just stick with a flat
DataTable? Would a collection be a better choice? What benefits will I
get from the DataRelations? If I set up a DataGrid on my form, can I
easily display, say, Job Number | Form Code | Record Filename, etc.? In
other words, if I'm not creating a database on some other server, do I
benefit by going to the trouble of normalizing the data in this way?

I'd appreciate any comments.

--
Michael Kellogg

I've used datatables and datasets as a cheap replacement for business
objects where I didn't have the will or time to do the hardwork myself.

That could be either overthinking it, or just taking a shortcut.

Here are a few reasons though of not using inbuilt objects like datasets -

a) You have enough time on your hands to create for yourself the specific
object you need.
b) Certain needs imposed by security, or remotability scenarios.
c) Custom serialization etc. needed.
d) Custom business logic required inside your object.
e) ... etc

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik




"Michael Kellogg" <(E-Mail Removed)> wrote in message
news:Xns95E964C357405mkelloggWEDELIVERcc3@207.46.248.16...
> I have an XML file I've created in another application that contains
> information on files, forms, and job header. My plan is, in my new
> "consumer" app, to read in this data and work with it, ultimately
> producing labels for shipping, etc.
>
> My planned approach is to construct a Dataset with 3 DataTables from this
> data: One table for job header; one table for form info; and one table
> for specific records. Then I want to set up one-to-many relations from
> the top, down.
>
> It's probably the SQL Server programmer in me that I'm taking this
> approach, am I overthinking it? Should I just stick with a flat
> DataTable? Would a collection be a better choice? What benefits will I
> get from the DataRelations? If I set up a DataGrid on my form, can I
> easily display, say, Job Number | Form Code | Record Filename, etc.? In
> other words, if I'm not creating a database on some other server, do I
> benefit by going to the trouble of normalizing the data in this way?
>
> I'd appreciate any comments.
>
> --
> Michael Kellogg

"Sahil Malik" <(E-Mail Removed)> wrote:

> I've used datatables and datasets as a cheap replacement for business
> objects where I didn't have the will or time to do the hardwork
> myself.
>
> That could be either overthinking it, or just taking a shortcut.
>
> Here are a few reasons though of not using inbuilt objects like
> datasets -
>
> a) You have enough time on your hands to create for yourself the
> specific object you need.
> b) Certain needs imposed by security, or remotability scenarios.
> c) Custom serialization etc. needed.
> d) Custom business logic required inside your object.
> e) ... etc
>
> - Sahil Malik
> http://dotnetjunkies.com/weblog/sahilmalik
>

Sahil, can you give me an example of an alternative way of going about
this, the "right" way? Or point me at an example somewhere. Thanks!

--
Michael Kellogg

"Sahil Malik" <(E-Mail Removed)> wrote:

> I've used datatables and datasets as a cheap replacement for business
> objects where I didn't have the will or time to do the hardwork
> myself.
>
> That could be either overthinking it, or just taking a shortcut.
>
> Here are a few reasons though of not using inbuilt objects like
> datasets -
>
> a) You have enough time on your hands to create for yourself the
> specific object you need.
> b) Certain needs imposed by security, or remotability scenarios.
> c) Custom serialization etc. needed.
> d) Custom business logic required inside your object.
> e) ... etc
>
> - Sahil Malik
> http://dotnetjunkies.com/weblog/sahilmalik
>

I should also point out that I've not been able to figure out how to get
a collection of custom objects (business objects?) to show up and be
editable in a DataGrid, which I always need to be able to do. That and
the fact that in my brain I normalize stuff like this, probably are why I
go this route. But I'm not convinced I'm doing it right.

--
Michael Kellogg

To make that happen, you need to implement IList on your business object.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik


"Michael Kellogg" <(E-Mail Removed)> wrote in message
news:Xns95E97239528D5mkelloggWEDELIVERcc3@207.46.248.16...
> "Sahil Malik" <(E-Mail Removed)> wrote:
>
>> I've used datatables and datasets as a cheap replacement for business
>> objects where I didn't have the will or time to do the hardwork
>> myself.
>>
>> That could be either overthinking it, or just taking a shortcut.
>>
>> Here are a few reasons though of not using inbuilt objects like
>> datasets -
>>
>> a) You have enough time on your hands to create for yourself the
>> specific object you need.
>> b) Certain needs imposed by security, or remotability scenarios.
>> c) Custom serialization etc. needed.
>> d) Custom business logic required inside your object.
>> e) ... etc
>>
>> - Sahil Malik
>> http://dotnetjunkies.com/weblog/sahilmalik
>>
>
> I should also point out that I've not been able to figure out how to get
> a collection of custom objects (business objects?) to show up and be
> editable in a DataGrid, which I always need to be able to do. That and
> the fact that in my brain I normalize stuff like this, probably are why I
> go this route. But I'm not convinced I'm doing it right.
>
> --
> Michael Kellogg

Michael,

There's no right way or wrong way, only what suits you. Either way has it's
own plusses and minuses.

What kinda example are you looking for? Are you looking at implementing your
own business objects kinda example? I'd recommend this book --

http://www.apress.com/book/bookDisplay.html?bID=284

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik




"Michael Kellogg" <(E-Mail Removed)> wrote in message
news:Xns95E971908DC1BmkelloggWEDELIVERcc3@207.46.248.16...
> "Sahil Malik" <(E-Mail Removed)> wrote:
>
>> I've used datatables and datasets as a cheap replacement for business
>> objects where I didn't have the will or time to do the hardwork
>> myself.
>>
>> That could be either overthinking it, or just taking a shortcut.
>>
>> Here are a few reasons though of not using inbuilt objects like
>> datasets -
>>
>> a) You have enough time on your hands to create for yourself the
>> specific object you need.
>> b) Certain needs imposed by security, or remotability scenarios.
>> c) Custom serialization etc. needed.
>> d) Custom business logic required inside your object.
>> e) ... etc
>>
>> - Sahil Malik
>> http://dotnetjunkies.com/weblog/sahilmalik
>>
>
> Sahil, can you give me an example of an alternative way of going about
> this, the "right" way? Or point me at an example somewhere. Thanks!
>
> --
> Michael Kellogg