On Wed, Jun 3, 2009 at 5:23 PM, keith Pope <[email protected]> wrote: > 2009/6/3 Matthew Weier O'Phinney <[email protected]>: >> -- [email protected] <[email protected]> wrote >> (on Wednesday, 03 June 2009, 02:13 PM -0500): >>> Andrew Ballard wrote: >>> > I have been looking over the data mapper pattern used in the current >>> > Quickstart. I like the separation of the data model from the storage, >>> > but I have a question. >>> > >>> > In the guestbook model, setId() and setCreated() are declared public. >>> > I realize this is necessary in the example because the values are >>> > being set by the mapper, which is external to the domain model class. >>> > However, I would think that it would be desirable some properties such >>> > as these one to be generally read-only. Is there any way to control >>> > which external classes are able to use these methods? Java has a >>> > package scope that would work, but PHP doesn't even have a concept of >>> > packages in its OO implementation. >>> > >>> > Andrew >>> > >>> If you can have the external classes be derived classes, then you can >>> make them protected and the derived classes can access them. >> >> But in the case of mappers, that doesn't work; the intention is to >> separate the domain objects from the data persistence, and this is done >> via the DataMapper. Having it extend the domain object would be >> counter-productive. > > Talking about data mappers and domain model, it may be important to > point out the quick start guide uses a very simple data mapper, in a > "real-life" situation you are going to need a much more complex data > mapper and to achieve a "true" domain model you need a lot of other > components that handle things like the object lifecycle etc (identity > map, unit of work patterns etc). Also in Martin Fowlers book he also > states that it better to buy a data mapper than try to implement one > yourself, this may point to the fact that data mappers are hard to > create! > > Obviously this is only my opinion I may be wrong :) > > On the note of data mappers, any news on how the data mapper proposal > is panning out? >
I'd be interested in seeing a larger example of what you mean. One of the things I like about this approach is that it looks like the domain model can be very simple and use a small memory footprint if done correctly. As for the idea of having to buy data mappers, that hardly seems workable to me. No one could possibly create a package of every possible data mapper that one might ever need to build an application, and I can't imagine that people working on smaller projects would have money to pay a specialist to develop custom mappers. One area of concern I have already is how things would change in a project that exclusively used stored procedures for working with the database. Would the data mapper be expanded to include the procedure calls themselves, or would you have to implement something to replace the DbTable classes? Stored procedures are not always just a wrapper for a simple SELECT/INSERT/UPDATE/DELETE statement on a single table. Andrew
