In regards to the RecordMapper / DataMapper, yes, simple, I have a pretty
good understanding of the concept behind that design pattern. From the
simplest of explanations I put in place business logic that links one to
one/one to many/many to many relationships between tables, through
inner/outer joins, and on deletes and stuff. I think it missed explaining
myself, as I am not so much looking for the ORM side of things as I am
looking for the logical side of things.
Note that an ORM like Doctrine provides mapping without you having to write a single line of database access code. I define my models with a yaml file and Doctrine generate tables. Doctrine has a lot of defects and from a OO design point of view probably it sucks, but it hides under the cover all the mapping and leaves you free to play with model logic.
<code>
</code>
Now as you can see, this is somewhat inconsistent with a pure OO model. So
what I am *thinking* is that I should have something like the following:
In fact, a "real" Data Mapper depends on model class, and not the inverse.
Controller -> Model -> DataMapper -> DataSource
If "->" is dependency, I think it's best from a DDD point of view:
Model <- DataMapper <- Repository, Factory, Services, etc. <- Controller
--
Giorgio Sironi
Piccolo Principe & Ossigeno Scripter
http://www.sourceforge.net/projects/ossigeno
没有评论:
发表评论