Structure problems (and I don't mean 'struct')

[0ddball]

I'm having a bit of a problem deciding which object should handle database serialization for a set of classes I've modeled.

Here's the scenario I'm dealing with:

                                         _____
                                  ???   /     \
               [ User Factory ] <-----> \_____/
                      |                 |     |
Find(string u);       |                 |  DB |
Create();             |                 |     |
???Update(User u);??? |                 \_____/
                      |                    ^
                      V           ???      |
                   [ User ]<----------------

So the question is... do I let the User object deal with the serialisation to the database (and also, I assume, decide WHEN to serialise) or do I let the factory serialise the data.

The other option is to create a completely new object (static?) to manage serialisation of my users (and later other things using the same model).

It's annoying that I can't afford to buy books on this kind of thing (application models) but I can't - if anyone can help me or maybe send me to a good site with lots of bright pictures and simple text (Spot writes code; Write code Spot; Spot writes good code; Good boy, Spot) I'd be mighty obliged !


Yet another unchecked rambling brought to you by:
Oddball

 

[chrissie1]

look for java daoobjects. Sounds weird but it has some good articles about this kind of things.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

something like this.



Christiaan Baes
Belgium

"My new site" - Me

 

[0ddball]

I don't think I've every really got the idea behind the concept of abstracting the data layer from the busniess layer.

If possible, could someone mark the following true/false statements? Comments welcome too...

1) Busniess level objects should have NO IDEA how the data is organised.

2) Data layer objects should have NO IDEA how the data is used.

3) I should write a busniess and a data object for every entity in my system.

4) Transfer objects represent things not processes and are therefor usualy 'dumb', containing little to no functionality.

5) To create a new user, say, I should call 'CreateUser()' in the busniess object which will, if no validation  (modification, etc) is nescecary, instantly call the data layer object 'CreateUser()' to add the user creating an effectivly transparent method.

6) The data layer, even though it is built to work with a persistant store, should also be abstract allowing many different data store types to be used (important in my app).

As I'm typing this I'm googling many differnt aspects of my question and it has brought me back to something someone mentioned in another of my structure questions - Enterprise Objects. Though they weren't the answer to my previous question they seem more relevent to this one.

What does everyone think?


Yet another unchecked rambling brought to you by:
Oddball

 

[chrissie1]

1) yep
2) yep
3) more or less yes, bussiness objects and data objects will seem similar but a database stores its data differently then a bussinessobject. For example a BO car has a collection of users in the database you will have three entities to represent that fact but not three dataobjects.
4) I guess you mean you model objects then yes but I wouldn't say they are dumb.
5)something like that
6) that is the whole point of the dao layering in that java article.


Christiaan Baes
Belgium

"My new site" - Me