Single Class vs Multiple Class

[vze1r2ht]

I have many types of classes and I'm deciding whether to use a single
class or multiple classes for EACH type of class.

For an example:

User class has 3 classes associated with it:

User Class - Holds user properties. Has NO DB related methods (infact
has NO methods, only properties lol) etc
User Collection class - Holds a collection of user objects
User Manager Class - Performs all Saving/Loading/Creating operations
for a user object/collections.

Should I have all the functions/methods in User Manager class inside
the User class? I read some where that this is the BEST way and that I
should stop using a "manager" class because its the "old technique" of
coding back in the days of fortran.

Also, if I use a single class like User and store it in the
session...does it store all the methods and functions too? That could
be very costly.

A good thing I guess about having the 3 classes is that my DAL is
implemented in only the User Manager class.


So is single or multiple classes better?

 

[Greg Young]

As to being an "old" technique .. this pattern is still happily alive and
well (known as the repository pattern) at the domain layer.

Seperating the data operations from the user object (which has its own
behaviors) is actually generally considerred a good thing as it will make
you code a bit more flexible. There is however a question as to whether or
not that flexibility is needed in your system. If it is not a simpler
pattern like Active Record might be better suited for you.

Cheers,

Greg Young
MVP - C#

 

[Hans Kesting]

Also, if I use a single class like User and store it in the
session...does it store all the methods and functions too? That could
be very costly.

The *code* is stored once per application, no matter how many instances
you have. In the heap (or on the stack - for ValueType variables) only
"data" is stored, so adding methods does not alter the amount of heap
used.

Hans Kesting

 

[Ludwig]

I have many types of classes and I'm deciding whether to use a single
class or multiple classes for EACH type of class.

For an example:

User class has 3 classes associated with it:

User Class - Holds user properties. Has NO DB related methods (infact
has NO methods, only properties lol) etc
User Collection class - Holds a collection of user objects
User Manager Class - Performs all Saving/Loading/Creating operations
for a user object/collections.

Should I have all the functions/methods in User Manager class inside
the User class? I read some where that this is the BEST way and that I
should stop using a "manager" class because its the "old technique" of
coding back in the days of fortran.

Also, if I use a single class like User and store it in the
session...does it store all the methods and functions too? That could
be very costly.

A good thing I guess about having the 3 classes is that my DAL is
implemented in only the User Manager class.


So is single or multiple classes better?

I still do this kind of seperation, to separate managing the data from
the data itself.
- Business object: holds properties, business rules
- Business object collection: strongly typed collection of a business
object (inherit from Collectionbase)
- Data manager: read/write to database

Of course, in 2.0 the Business object collection can be replaced by a
generic collection.

I like the fact that my business objects are not bound to a specific
data behavior.

 

[Greg Young]

As for being replaced by a generic collection. In my experience in the
domain layer it is always best to close the type for a collection ... i.e.

public class UserCollection : Collection<User> {}

Even if you are not adding functionality as you may need to add collection
behaviors in the future. It is also considerred bad practice by many to
return something like Collection<User> from the domain layer.

Cheers,

GReg