RE: [aus-dotnet] Many instance variables inside a class


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
    • From: Daryl Sivies
    • Subject: RE: [aus-dotnet] Many instance variables inside a class
    • Date: Sat, 11 Dec 2004 13:19:27 +1100

    Lots of properties are evil if your object is being called remotely and the
    caller has to make multiple trips. If the object is local, not a problem.
    
    Do you need all the properties? Just because the database has 70 columns
    doesn't mean your business object needs 70 properties. The business object
    may ignore some of the data, merge some of the data, or derive additional
    properties.
    
    -----Original Message-----
    From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On Behalf
    Of Grant Maw
    Sent: Friday, 10 December 2004 11:53 AM
    To: dotnet@xxxxxxxxxxx
    Subject: Re: [aus-dotnet] Many instance variables inside a class
    
    Thanks all for the replies. Seems that having lots of properties might
    not be such an evil thing to do after all (though I do recall reading
    on some guru's blog that one should always try to have more methods
    than properties in one's classes).
    
    The class is daunting to new programmers who have never used it
    before, so perhaps grouping related data into structs might be the
    answer.
    
    Cheers!
    
    On Fri, 10 Dec 2004 11:30:19 +1100, David Kean <David.Kean@xxxxxxxxxxx>
    wrote:
    > Well, you could break the Person down into 'properties' classes, however
    > classes with just data and no methods just feel wrong.
    > 
    > For example:
    > 
    > Instead of:
    > 
    > Person.Title
    > Person.FirstName
    > Person.MiddleName
    > Person.LastName
    > 
    > Have
    > 
    > Person.Name.Title
    > Person.Name.FirstName
    > Person.Name.MiddleName
    > Person.Name.LastName
    > 
    > Where Name is a instance class of a PersonName class with those
    > properties.
    > 
    > It will make Person a little easier to deal with, being confronted with
    > 70 properties can be daunting.
    > 
    > 
    > 
    > -----Original Message-----
    > From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On
    > Behalf Of Grant Maw
    > Sent: Friday, 10 December 2004 11:23 AM
    > To: dotnet@xxxxxxxxxxx
    > Subject: Re: [aus-dotnet] Many instance variables inside a class
    > 
    > The data has already been normalised to 3NF. This is a massive database
    > and if we did not have normalised data the whole thing would have come
    > crashing down around our ears years ago.
    > 
    > All I'm after is a way to represent any entity that, by it's nature, has
    > lots and lots of data attached to it. It feels to me that having a class
    > with so many properties is using the class incorrectly - using it as a
    > bucket of bits rather than as a functional entity.
    > 
    > On Fri, 10 Dec 2004 11:16:28 +1100, David Kean <David.Kean@xxxxxxxxxxx>
    > wrote:
    > > Yep it's called normalizing!  70 columns for 1 table sounds way too
    > > many, have you thought about looking at the database side first?
    > >
    > >
    > >
    > > -----Original Message-----
    > > From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On
    > > Behalf Of Grant Maw
    > > Sent: Friday, 10 December 2004 11:13 AM
    > > To: dotnet@xxxxxxxxxxx
    > > Subject: [aus-dotnet] Many instance variables inside a class
    > >
    > > Hi all
    > >
    > > I have a situation where I have a class called "Person" which, rather
    > > obviously, holds the data and methods for working with the Person
    > > entity in our app.
    > >
    > > The DB entry for a person has some 70 columns and this has translated
    > > into 70 properties of the Person class. There is one method to load
    > > the data rom the DB, and another to update it. The update method does
    > > all the validation and throws exceptions if any of the data violates
    > > business rules.
    > >
    > > The class works well so maybe I'm over-reacting here, but having a
    > > class with such a large number of properties just feels wrong. I
    > > haven't found anything in MSDN that explicitly deals with this
    > > situation.
    > >
    > > Is there a better way of dealing with situations where an entity has
    > > lots of different properties?
    > >
    > > Cheers
    > >
    > > - Grant
    > > _________________
    > > You are a part of the Australian "dotnet" mailing list.
    > > To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
    > > "subscribe dotnet Your Name" in the body of the email to:
    > > imailsrv@xxxxxxxxxxx List managed by: http://www.stanski.com 
    > > ######################################################################
    > > ###############
    > 
    > 
    > > Attention:
    > > The information contained in this message and or attachments is
    > intended
    > > only for the person or entity to which it is addressed and may contain
    > > confidential and/or privileged material. Any review, retransmission,
    > > dissemination or other use of, or taking of any action in reliance
    > upon,
    > > this information by persons or entities other than the intended
    > recipient
    > > is prohibited. If you received this in error, please inform us by
    > email at
    > > postmaster@xxxxxxxxxxx and delete the material from any system.
    > >
    > ########################################################################
    > #############
    > > _________________
    > > You are a part of the Australian "dotnet" mailing list.
    > > To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
    > "subscribe dotnet Your Name" in the body of the email to:
    > imailsrv@xxxxxxxxxxx
    > > List managed by: http://www.stanski.com
    > >
    > _________________
    > You are a part of the Australian "dotnet" mailing list.
    > To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
    > "subscribe dotnet Your Name" in the body of the email to:
    > imailsrv@xxxxxxxxxxx List managed by: http://www.stanski.com
    >
    ############################################################################
    #########
    > 
    > 
    > Attention:
    > The information contained in this message and or attachments is intended
    > only for the person or entity to which it is addressed and may contain
    > confidential and/or privileged material. Any review, retransmission,
    > dissemination or other use of, or taking of any action in reliance upon,
    > this information by persons or entities other than the intended recipient
    > is prohibited. If you received this in error, please inform us by email at
    > postmaster@xxxxxxxxxxx and delete the material from any system.
    >
    ############################################################################
    #########
    > _________________
    > You are a part of the Australian "dotnet" mailing list.
    > To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
    "subscribe dotnet Your Name" in the body of the email to:
    imailsrv@xxxxxxxxxxx
    > List managed by: http://www.stanski.com
    >
    _________________
    You are a part of the Australian "dotnet" mailing list.
    To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe
    dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
    List managed by: http://www.stanski.com
    
    
    _________________
    You are a part of the Australian "dotnet" mailing list.
    To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
    List managed by: http://www.stanski.com
    
    



    (Click here for more information on the aus-dotnet mailling list)