Confused...Objects versus Datasets

[Paul F]

I'm a little confused in trying to design an application using dotNet.
Usually, we wrap objects that describe a set of data and behaviour. As an
example I'll explain 2 objects Customer and Reservation. Both are independant
of each other in an object oriented way and from a data standpoint. The confusion
comes when trying to model these 2 objects together as a Booking Object (Booking
contains Reservation and Customer).
Do I now use a seperate Booking object that aggregates 2 seperate Reservation
and Customer objects that use dataset to maintain their state or do I use
a Booking dataset that just has 2 tables Reservation and Customer? (Essentially
the datasets become the object without the behaviour). I'm at a loss for
what way to approach this!!
Any ideas/help appreciated
Thanks
Paul

[Greg Gates]

Hi Paul:

My first instinct would be to retrieve the customer and reservation data
in a single dataset and unpack it into a booking object that contained customer
and reservation objects. I don't like using datasets to maintain state or
perform data modifications. I find the design becomes too dependent on the
dataset and has less clarity. Curious what others are doing, though.

thanks, Greg



"Paul F" <paulfarnan@hotmai.com> wrote:
>
>I'm a little confused in trying to design an application using dotNet.
>Usually, we wrap objects that describe a set of data and behaviour. As an
>example I'll explain 2 objects Customer and Reservation. Both are independant
>of each other in an object oriented way and from a data standpoint. The
confusion
>comes when trying to model these 2 objects together as a Booking Object
(Booking
>contains Reservation and Customer).
>Do I now use a seperate Booking object that aggregates 2 seperate Reservation
>and Customer objects that use dataset to maintain their state or do I use
>a Booking dataset that just has 2 tables Reservation and Customer? (Essentially
>the datasets become the object without the behaviour). I'm at a loss for
>what way to approach this!!
>Any ideas/help appreciated
>Thanks
>Paul

[Paul F]

I was thinking of doing this only that you have to programatically look after
the relationships between the independant objects. I know you have to do
this anyway but I'm not sure if is easier to do with the Data relation object
and datasets as they seem to claim to be the case.
Also, these objects (Customer & Reservation) don't really exist on their
own, just as composite objects inside the Booking object but they have to
be logically split at the database level by rules of normalisation.
My problem is I don't want to go and program an object model the traditional
way and finding out in 3 months time that all the work is done in the DataSet/Data
relation objects for me. Does it not seem that all that the dataset/data
relation model brings to us is the complexities that usually the database
would look after?
Feeling a little bemused....@#$$#@!*(&^%$#@@!

"Greg Gates" <ggates@capcollege.bc.ca> wrote:
>
>Hi Paul:
>
>My first instinct would be to retrieve the customer and reservation data
>in a single dataset and unpack it into a booking object that contained customer
>and reservation objects. I don't like using datasets to maintain state or
>perform data modifications. I find the design becomes too dependent on the
>dataset and has less clarity. Curious what others are doing, though.
>
>thanks, Greg
>
>
>
>"Paul F" <paulfarnan@hotmai.com> wrote:
>>
>>I'm a little confused in trying to design an application using dotNet.
>>Usually, we wrap objects that describe a set of data and behaviour. As
an
>>example I'll explain 2 objects Customer and Reservation. Both are independant
>>of each other in an object oriented way and from a data standpoint. The
>confusion
>>comes when trying to model these 2 objects together as a Booking Object
>(Booking
>>contains Reservation and Customer).
>>Do I now use a seperate Booking object that aggregates 2 seperate Reservation
>>and Customer objects that use dataset to maintain their state or do I use
>>a Booking dataset that just has 2 tables Reservation and Customer? (Essentially
>>the datasets become the object without the behaviour). I'm at a loss for
>>what way to approach this!!
>>Any ideas/help appreciated
>>Thanks
>>Paul
>

[MarkN]

Paul,
You are not alone in this. Persisting Objects in a Relational Database
is not easy and usually requires some give and take. I usually end up having
to use Relational specific things like triggers to get it all to work.

I try to separate my Persistance from my business objects by providing a
generic peristance object that handles the the peristance knowledge. I would
have a BookingPersist object with a retrieve by ID method that returns a
Booking object that contains all of the necessary Customer and Reservation
Objects. The retrieve method would now how to get and build the objects
whether it was via pure XML, DataSets, pure SQL, flat files, etc.

In other OO language worlds there are multiple choices for Object to Relational
Mapping from OpenSource to Big Bucks. Unfortunately there doesn't seem to
be much else for .Net besides the little MS is offering.
You might try using a Object Database.


Mark


"Paul F" <paulfarnan@hotmail.com> wrote:
>
>I was thinking of doing this only that you have to programatically look
after
>the relationships between the independant objects. I know you have to do
>this anyway but I'm not sure if is easier to do with the Data relation object
>and datasets as they seem to claim to be the case.
>Also, these objects (Customer & Reservation) don't really exist on their
>own, just as composite objects inside the Booking object but they have to
>be logically split at the database level by rules of normalisation.
>My problem is I don't want to go and program an object model the traditional
>way and finding out in 3 months time that all the work is done in the DataSet/Data
>relation objects for me. Does it not seem that all that the dataset/data
>relation model brings to us is the complexities that usually the database
>would look after?
>Feeling a little bemused....@#$$#@!*(&^%$#@@!
>
>"Greg Gates" <ggates@capcollege.bc.ca> wrote:
>>
>>Hi Paul:
>>
>>My first instinct would be to retrieve the customer and reservation data
>>in a single dataset and unpack it into a booking object that contained
customer
>>and reservation objects. I don't like using datasets to maintain state
or
>>perform data modifications. I find the design becomes too dependent on
the
>>dataset and has less clarity. Curious what others are doing, though.
>>
>>thanks, Greg
>>
>>
>>
>>"Paul F" <paulfarnan@hotmai.com> wrote:
>>>
>>>I'm a little confused in trying to design an application using dotNet.
>>>Usually, we wrap objects that describe a set of data and behaviour. As
>an
>>>example I'll explain 2 objects Customer and Reservation. Both are independant
>>>of each other in an object oriented way and from a data standpoint. The
>>confusion
>>>comes when trying to model these 2 objects together as a Booking Object
>>(Booking
>>>contains Reservation and Customer).
>>>Do I now use a seperate Booking object that aggregates 2 seperate Reservation
>>>and Customer objects that use dataset to maintain their state or do I
use
>>>a Booking dataset that just has 2 tables Reservation and Customer? (Essentially
>>>the datasets become the object without the behaviour). I'm at a loss for
>>>what way to approach this!!
>>>Any ideas/help appreciated
>>>Thanks
>>>Paul
>>
>

[Greg Gates]

Hi Paul:

Interesting dilemma, isn't it!?

I decided not to use a dataset-centric design for the following reasons:

Concern over flexibility. If I rely on the dataset, will I lose flexibility?

Concern over clarity of design. Will a dataset-centric design wind up being
overly convoluted?

Concern over the lifespan of ADO.NET. I don't want my design to be overly
dependent on the latest, greatest data access technology. I used only the
basic functionality of ADO 2.5 in my last VB6 design and I certainly don't
regret that.

I use ADO.NET to:

- retrieve data and populate my business objects
- retrieve data to be used as a data source for Crystal.NET.
- retrieve static / semi-static data to be cached in the middle-tier


thanks, Greg



"Paul F" <paulfarnan@hotmail.com> wrote:
>
>I was thinking of doing this only that you have to programatically look
after
>the relationships between the independant objects. I know you have to do
>this anyway but I'm not sure if is easier to do with the Data relation object
>and datasets as they seem to claim to be the case.
>Also, these objects (Customer & Reservation) don't really exist on their
>own, just as composite objects inside the Booking object but they have to
>be logically split at the database level by rules of normalisation.
>My problem is I don't want to go and program an object model the traditional
>way and finding out in 3 months time that all the work is done in the DataSet/Data
>relation objects for me. Does it not seem that all that the dataset/data
>relation model brings to us is the complexities that usually the database
>would look after?
>Feeling a little bemused....@#$$#@!*(&^%$#@@!
>

[MarkN]

Greg,

So how do you retrieve your data in ADO.Net?

BTW, it might be better to use the business objects to supply data to your
reports. If not you may end up getting business logic duplicated in your
Reports. Just think of them as another UI.

Mark

"Greg Gates" <ggates@capcollege.bc.ca> wrote:
>
>Hi Paul:
>
>Interesting dilemma, isn't it!?
>
>I decided not to use a dataset-centric design for the following reasons:
>
>Concern over flexibility. If I rely on the dataset, will I lose flexibility?
>
>Concern over clarity of design. Will a dataset-centric design wind up being
>overly convoluted?
>
>Concern over the lifespan of ADO.NET. I don't want my design to be overly
>dependent on the latest, greatest data access technology. I used only the
>basic functionality of ADO 2.5 in my last VB6 design and I certainly don't
>regret that.
>
>I use ADO.NET to:
>
>- retrieve data and populate my business objects
>- retrieve data to be used as a data source for Crystal.NET.
>- retrieve static / semi-static data to be cached in the middle-tier
>
>
>thanks, Greg
>
>
>
>"Paul F" <paulfarnan@hotmail.com> wrote:
>>
>>I was thinking of doing this only that you have to programatically look
>after
>>the relationships between the independant objects. I know you have to do
>>this anyway but I'm not sure if is easier to do with the Data relation
object
>>and datasets as they seem to claim to be the case.
>>Also, these objects (Customer & Reservation) don't really exist on their
>>own, just as composite objects inside the Booking object but they have
to
>>be logically split at the database level by rules of normalisation.
>>My problem is I don't want to go and program an object model the traditional
>>way and finding out in 3 months time that all the work is done in the DataSet/Data
>>relation objects for me. Does it not seem that all that the dataset/data
>>relation model brings to us is the complexities that usually the database
>>would look after?
>>Feeling a little bemused....@#$$#@!*(&^%$#@@!
>>
>

[Greg Gates]

Hi Mark:

I use a dataset to retrieve data. I don't use a datareader very often, as
I pass the dataset between tiers.

In Crystal.NET, I create a class that inherits from the autogenerated class
that Crystal provides. Within that class, I call a business object that calls
a data access object that calls a stored procedure. The resultant dataset
is passed up through the tiers and used as the datasource of the report.
With this design I can create and populate a report with a single line of
code.

i.e.
ReportDocument report =
new JournalEntryPayrollX(GetLogon(),GetMonthId(),GetPayrollType();

Doesn't matter if it is a Windows front end or a Web front end.

Most of the business logic for determining report data is in the stored procedure.
Given that reporting is primarily a set based problem, I find a set based
language like SQL to far superior.

thanks, Greg


"MarkN" <m@n.com> wrote:
>
>Greg,
>
> So how do you retrieve your data in ADO.Net?
>
>BTW, it might be better to use the business objects to supply data to your
>reports. If not you may end up getting business logic duplicated in your
>Reports. Just think of them as another UI.
>
>Mark
>

[MarkN]

Thanks for the response. I'm currently using Datasets because I'm tired of
writing SQL for simple stuff. Wasn't sure how other were doing it.

Won't discuss(argue) the report thing - other than to say I avoid using stored
procs because they end up embeding business logic in the database and tie
me too much to a certain database. If you never plan to change databases
then it is not an issue. I'm sure it is fast though. Also, if I need to
make changes to persistance then I have to find all the reports that use
the database table/field.

Mark


"Greg Gates" <ggates@capcollege.bc.ca> wrote:
>
>Hi Mark:
>
>I use a dataset to retrieve data. I don't use a datareader very often, as
>I pass the dataset between tiers.
>
>In Crystal.NET, I create a class that inherits from the autogenerated class
>that Crystal provides. Within that class, I call a business object that
calls
>a data access object that calls a stored procedure. The resultant dataset
>is passed up through the tiers and used as the datasource of the report.
>With this design I can create and populate a report with a single line of
>code.
>
>i.e.
>ReportDocument report =
>new JournalEntryPayrollX(GetLogon(),GetMonthId(),GetPayrollType();
>
>Doesn't matter if it is a Windows front end or a Web front end.
>
>Most of the business logic for determining report data is in the stored
procedure.
>Given that reporting is primarily a set based problem, I find a set based
>language like SQL to far superior.
>
>thanks, Greg
>
>
>"MarkN" <m@n.com> wrote:
>>
>>Greg,
>>
>> So how do you retrieve your data in ADO.Net?
>>
>>BTW, it might be better to use the business objects to supply data to your
>>reports. If not you may end up getting business logic duplicated in your
>>Reports. Just think of them as another UI.
>>
>>Mark
>>

[Michael Culley]

Mark, greg, paul,

I am currently create business objects that wrap the dataset fairly closely.
Its too early to say if it is successful or not but it seams to be working
fairly well. In VB6 I had to run through a recordset and copy the results
into variables in each object in the collection. In .net I just pass in a
reference to the row in the dataset. I don't need to keep state such as
deleted etc because the dataset does this for me. I manage to keep the full
funtionality of an oop approach as the dataset is wrapped in the class and
not exposed.

--
Michael Culley
www.vbdotcom.com

[Mark]

Michael,
This is what I'm currently doing (Just in case it wasn't clear ).

Mark

"Michael Culley" <m_culley@hotmail.com> wrote:
>Mark, greg, paul,
>
>I am currently create business objects that wrap the dataset fairly closely.
>Its too early to say if it is successful or not but it seams to be working
>fairly well. In VB6 I had to run through a recordset and copy the results
>into variables in each object in the collection. In .net I just pass in
a
>reference to the row in the dataset. I don't need to keep state such as
>deleted etc because the dataset does this for me. I manage to keep the full
>funtionality of an oop approach as the dataset is wrapped in the class and
>not exposed.
>
>--
>Michael Culley
>www.vbdotcom.com
>
>
>

[Greg Gates]

Hi Michael:

I had thought about this idea but got cold feet.
I must admit, it is a very interesting idea.
I'd like to see a full-blown implementation of this concept and evaluate
all the advantages and disadvantages. I'm sure something along these lines
will be available soon.

My immediate concerns would be regarding the clarity and flexibility of the
code. Also, is it wise to have a design that is so dependant on the functionality
of the ADO.NET dataset? I was port my existing VB6 ADO code with relative
ease because I did not take advantage of the many ADO bells and whistles.

On the other hand, it could turn out to be a terrific way to design.

thanks, Greg



"Michael Culley" <m_culley@hotmail.com> wrote:
>Mark, greg, paul,
>
>I am currently create business objects that wrap the dataset fairly closely.
>Its too early to say if it is successful or not but it seams to be working
>fairly well. In VB6 I had to run through a recordset and copy the results
>into variables in each object in the collection. In .net I just pass in
a
>reference to the row in the dataset. I don't need to keep state such as
>deleted etc because the dataset does this for me. I manage to keep the full
>funtionality of an oop approach as the dataset is wrapped in the class and
>not exposed.
>
>--
>Michael Culley
>www.vbdotcom.com
>
>
>

[Paul F]

Michael, Mark, Greg,
My question is: do you model object relationships in the data set or do you
do it programatically?
I'm having trouble of how to go about this with datasets! I'm tempted just
to use dataset the same way as I was using ADO 2.6. Esentially, my booking
object contains multiple customer objects and a single reservation object.
When I go to the database to get this information do I use a booking data
set that contains a reservation table with a single row and a customer table
with multiple rows and use a data relation object to manage the relationship
between these 2 or do I just use 2 seperate datasets with one table in each
- one for the reservation and one for the customer?
Does it make a difference really? Essentially I'll have to use two seperate
data adapters to update each table anyway?

I was thinking of passing around the dataset as the state of the objects
and just passing the dataset to each respesctive object when committing objects
to the database. Each respective object then has the corresponding data adapter
to commit the changes of the dataset.

btw - are you passing an actual reference to the dataset row object as in
Data.DataRow or just a reference to the dataset?

Thanks for all your input !!!

"Mark" <m@n.com> wrote:
>
>Michael,
> This is what I'm currently doing (Just in case it wasn't clear ).
>
>Mark
>
>"Michael Culley" <m_culley@hotmail.com> wrote:
>>Mark, greg, paul,
>>
>>I am currently create business objects that wrap the dataset fairly closely.
>>Its too early to say if it is successful or not but it seams to be working
>>fairly well. In VB6 I had to run through a recordset and copy the results
>>into variables in each object in the collection. In .net I just pass in
>a
>>reference to the row in the dataset. I don't need to keep state such as
>>deleted etc because the dataset does this for me. I manage to keep the
full
>>funtionality of an oop approach as the dataset is wrapped in the class
and
>>not exposed.
>>
>>--
>>Michael Culley
>>www.vbdotcom.com
>>
>>
>>
>

[Greg Gates]

Hi Paul:

My opinion.

I would use a single dataset that contained a reservation table and a customer
table. I would then unpack the data into reservation and customer objects
contained within the booking object. Finally, I would persist the booking
object by passing it to my data access tier and calling a parameterized stored
procedure. I wouldn't use the persistence capabilities of the dataset object.
The data access tier would not receive a dataset, but an actual booking object.
It would know how to read the booking object as it would have a reference
to an interface implemented by the booking object. (i.e. booking object would
implement IBooking interface which would be housed in a separate DLL. The
data access tier would also have a reference to this DLL, and be able to
accept objects of type IBooking)

thanks, Greg

thanks, Greg


"Paul F" <pf@hotmail.com> wrote:
>
>Michael, Mark, Greg,
>My question is: do you model object relationships in the data set or do
you
>do it programatically?
>I'm having trouble of how to go about this with datasets! I'm tempted just
>to use dataset the same way as I was using ADO 2.6. Esentially, my booking
>object contains multiple customer objects and a single reservation object.
>When I go to the database to get this information do I use a booking data
>set that contains a reservation table with a single row and a customer table
>with multiple rows and use a data relation object to manage the relationship
>between these 2 or do I just use 2 seperate datasets with one table in each
>- one for the reservation and one for the customer?
>Does it make a difference really? Essentially I'll have to use two seperate
>data adapters to update each table anyway?
>
>I was thinking of passing around the dataset as the state of the objects
>and just passing the dataset to each respesctive object when committing
objects
>to the database. Each respective object then has the corresponding data
adapter
>to commit the changes of the dataset.
>
>btw - are you passing an actual reference to the dataset row object as in
>Data.DataRow or just a reference to the dataset?
>
>Thanks for all your input !!!
>
>"Mark" <m@n.com> wrote:
>>

[Michael Culley]

Greg,

> I was port my existing VB6 ADO code with relative
> ease because I did not take advantage of the many ADO bells and whistles.

I can see your point here but I'm really just accepting that the method is
tied to a dataset. In VB6 I took the approach you decribed and it did work
quite well. The objects I am writing in .net work in a very similar manner
from the outside, so if I had to port them to another language it might be
possible.

Paul,

> My question is: do you model object relationships in the data set or do
you
> do it programatically?

I have not got this far yet, so far the objects just wrap individual tables.

> btw - are you passing an actual reference to the dataset row object as in
> Data.DataRow or just a reference to the dataset?

Yep, I'm passing in a reference to the row in the constructor. In VB6 I
would pass in the values to the object but passing in the row is so much
cleaner.

I am developing this at home and have only been doing it for the past couple
of weeks so cannot give a definate yes or no as to whether it is a good
method, but it does seem to be going quite well

Mark,

> This is what I'm currently doing (Just in case it wasn't clear ).

Can you give me any tips?

--
Michael Culley
www.vbdotcom.com


"Greg Gates" <ggates@capcollege.bc.ca> wrote in message
news:3c9a134c$1@10.1.10.29...
>
> Hi Michael:
>
> I had thought about this idea but got cold feet.
> I must admit, it is a very interesting idea.
> I'd like to see a full-blown implementation of this concept and evaluate
> all the advantages and disadvantages. I'm sure something along these lines
> will be available soon.
>
> My immediate concerns would be regarding the clarity and flexibility of
the
> code. Also, is it wise to have a design that is so dependant on the
functionality
> of the ADO.NET dataset? I was port my existing VB6 ADO code with relative
> ease because I did not take advantage of the many ADO bells and whistles.
>
> On the other hand, it could turn out to be a terrific way to design.
>
> thanks, Greg
>
>
>
> "Michael Culley" <m_culley@hotmail.com> wrote:
> >Mark, greg, paul,
> >
> >I am currently create business objects that wrap the dataset fairly
closely.
> >Its too early to say if it is successful or not but it seams to be
working
> >fairly well. In VB6 I had to run through a recordset and copy the results
> >into variables in each object in the collection. In .net I just pass in
> a
> >reference to the row in the dataset. I don't need to keep state such as
> >deleted etc because the dataset does this for me. I manage to keep the
full
> >funtionality of an oop approach as the dataset is wrapped in the class
and
> >not exposed.
> >
> >--
> >Michael Culley
> >www.vbdotcom.com
> >
> >
> >
>