Quote Originally Posted by MickoZ
The reason to have two classes (User and UserMapper) is to separate two different topic even thought they can be linked to one topic.
I am working from the description of a mapper class given at the start of this thread by JNKlein:
Quote Originally Posted by JNKlein
Let me use the example of the User class, something I'm sure we're all familiar with. Suppose one of the properties of a "user" is "username". You whip up your User class, then you whip up a UserMapper class, which has a method insert(User). The internals of this method inevitably make specific reference to the properties of a User object AND inevitably make specific reference to your method of storing the data (even with a DAO you need to specifically state where you are putting the info... "INSERT ... WHERE username = etc).
This appears to be saying that when I wish to perform a function on a User which does not involve database access then I use the User class, while if it DOES involve database access then I must use the UserMapper class. This is what I absolutely disagree with. By having more than one class available when I wish to perform a function on a User is breaking encapsulation. It also forces the calling script to know what kind of activity it requires so that it can call the right class. Because this information is required OUTSIDE the class it also breaks the principle of information hiding.

Now, if it were arranged so that I only ever accessed the User class, and if the code within that class decided that some database access were required and it accessed the UserMapper class without me even being aware of it, then that would be a step in the right direction.

But hang on a minute! isn't that what I already have in my design? Except that in my case I don't have a UserMapper class, I have a Data Access Object. Also I don't have a separate Mapper class for each entity, but I do have a single data access object for the entire application. Somehow my design seems more efficient.