Re: [fw-general] DataMapper questions from Quickstart
On Wed, Jun 3, 2009 at 5:23 PM, keith Pope wrote: > 2009/6/3 Matthew Weier O'Phinney : >> -- mi...@onshore.com 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
Re: [fw-general] DataMapper questions from Quickstart
On Wed, Jun 3, 2009 at 2:34 PM, Matthew Weier O'Phinney wrote: > -- Andrew Ballard wrote > (on Wednesday, 03 June 2009, 09:47 AM -0400): >> 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. > > PHP doesn't have such a concept. One way to get around it is to only > allow setting of particular properties by passing them to the > constructor, which is a technique I've often seen. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > I know the concept of friend/package scope doesn't exist in PHP. From a purely theoretical OO perspective, maybe it should not exist in any language: When you want to modify an object from outside, you should communicate directly with one of its public interfaces. Still, when making the leap from the theoretical to the practical, it seems that often you need a way of allowing SOME external objects to access methods that most other external objects cannot. I've tried the technique you mentioned before (not related to this data mapper model). It doesn't completely lock things down, but it seems to be a step in the right direction. The example project is already built to do this by accepting an array that it hands off to setOptions(), which will load any properties whose name matches a setter method in the class. What about an approach that extends that idea somewhat by adding a way to trigger the domain model (for instance, in its constructor, its setMapper method, or perhaps a new load() method) to call a special getMappedData() method in the mapper that would return a structured set of properties (an array, stdClass, etc.). The model would then process the data returned from the mapper to initialize its own properties. This way the model keeps the responsibility for setting its own properties by accessing data from a class that it trusts. It seems to me that this drastically restricts the ability for an external class to inject anything. My concern is that the model and the mapper then become tightly coupled. Would having the mapper implement a Zend_DataMapper_Interface be sufficient to decouple them? Would the risk that another class could easily impersonate a trusted data mapper by implementing the interface nullify any benefit gained? Andrew
Re: [fw-general] DataMapper questions from Quickstart
2009/6/3 Matthew Weier O'Phinney : > -- mi...@onshore.com 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? > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ > -- -- [MuTe] --
Re: [fw-general] DataMapper questions from Quickstart
-- mi...@onshore.com 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. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] DataMapper questions from Quickstart
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. -- Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com
Re: [fw-general] DataMapper questions from Quickstart
-- Andrew Ballard wrote (on Wednesday, 03 June 2009, 09:47 AM -0400): > 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. PHP doesn't have such a concept. One way to get around it is to only allow setting of particular properties by passing them to the constructor, which is a technique I've often seen. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
[fw-general] DataMapper questions from Quickstart
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
