Confused...Objects versus Datasets


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 14 of 14

Thread: Confused...Objects versus Datasets

  1. #1
    Paul F Guest

    Confused...Objects versus Datasets


    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

  2. #2
    Greg Gates Guest

    Re: Confused...Objects versus Datasets


    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



  3. #3
    Paul F Guest

    Re: Confused...Objects versus Datasets


    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

    >



  4. #4
    MarkN Guest

    Re: Confused...Objects versus Datasets


    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

    >>

    >



  5. #5
    Greg Gates Guest

    Re: Confused...Objects versus Datasets


    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....@#$$#@!*(&^%$#@@!
    >



  6. #6
    MarkN Guest

    Re: Confused...Objects versus Datasets


    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....@#$$#@!*(&^%$#@@!
    >>

    >



  7. #7
    Greg Gates Guest

    Re: Confused...Objects versus Datasets


    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
    >


  8. #8
    MarkN Guest

    Re: Confused...Objects versus Datasets


    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
    >>



  9. #9
    Michael Culley Guest

    Re: Confused...Objects versus Datasets

    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




  10. #10
    Mark Guest

    Re: Confused...Objects versus Datasets


    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
    >
    >
    >



  11. #11
    Greg Gates Guest

    Re: Confused...Objects versus Datasets


    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
    >
    >
    >



  12. #12
    Paul F Guest

    Re: Confused...Objects versus Datasets


    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
    >>
    >>
    >>

    >



  13. #13
    Greg Gates Guest

    Re: Confused...Objects versus Datasets


    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:
    >>



  14. #14
    Michael Culley Guest

    Re: Confused...Objects versus Datasets

    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
    > >
    > >
    > >

    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center