your business objects (i.e. Site) from the DB, they don't have to
correspond exactly to the DB's structure. This is valuable when you
really want to do things with your objects that cannot be easily
expressed by the DB schema. (Applying many design patterns would cause
this.) OTOH, if your business domain naturally corresponds closely to
the DB structure, and doesn't involve a lot of object interactions, you
can save yourself all the extra complexity of the data mapper by using
plain table data gateways or active record classes.
Hope this helps,
Bryce Lohr
Jack Sleight wrote:
> OK, think I'm getting my head round this now :-) . So, my "gateway" is
> actually a data mapper, and that is used to hide the domain objects
> from the DB and vice-versa. A script will access the mapper, request a
> Site object, the mapper will do all the DB work, create a Site object
> from the data and then return that object. When the object has been
> updated and the changes need to be saved back to the DB the object is
> parsed back to the mapper, which again takes care of the DB work.
>
> The DB knows nothing about the mapper or the domain objects.
> The domain objects no nothing about the mapper or the DB.
> The mapper knows about both the DB and the domain objects.
>
> Am I on the right lines?
>
没有评论:
发表评论