Re: [fw-general] Models as Singletons
> That boost can also occur if you simply do metadata caching, per the > performance recommendations. ;) Truly, that's the single easiest way to > improve performance in Zend_Db_Table, and it has huge impact, > particularly if you instantiate multiple copies of the table within your > app. > > Using a singleton for performance reasons is almost always the wrong > solution; look instead at how the objects that depend on it get the > dependency. Thanks Everyone - that helped clarify things =) -Ed
Re: [fw-general] Models as Singletons
-- Ed Lazor wrote (on Thursday, 23 July 2009, 02:22 PM -0700): > I realize some people are saying that Singletons should never be used. > If that's the case, why are they used in Zend Framework? For > example, Zend_Auth, Zend_Registry, Zend_Loader_Autoloader, and > Zend_Controller_Front. Aren't these good examples of where Singletons > are beneficial? Some are, and some are not. Zend_Auth, Zend_Session, and Zend_Loader_Autoloader are examples where they make sense. There is only one $_SESSION superglobal (Zend_Auth is a singleton because it utilizes Zend_Session under the hood), and only one spl_autoload registry; what they each operate on is singular in nature, and thus the singleton makes sense. (That said, because $_SESSION is globally available, Zend_Session could easily be refactored to remove the singleton as well.) Zend_Registry is an interesting hybrid. The main use case most people write towards is its global registry nature. However, it can also be instantiated directly and used as a local registry (Zend_Tool uses it in this way, as does Zend_Application). I personally only ever use Zend_Registry as a global registry when debugging -- I'll place a log object in it and pull that to log information from my controller, models, or views... but I *always* strip those calls out once the problem has been isolated. Zend_Controller_Front's reasons for being a singleton are not very good. At the time we decided to make it one, the argument was that for any given request, there could only be one front controller in play. However, there are some use cases where this actually is a hindrance -- one in particular is if you want to *extend* it to alter or add functionality. My plan for 2.0 is to remove the singleton. > How do you know when it's ok to use Singletons? It seems like > Singletons are beneficial, when used to share a single resource, > because they have the potential for improving performance, and > reducing application complexity. Remove the performance argument from this; you get good performance as well by simply passing dependencies into other objects, as objects are passed by reference. Also remove the "reducing application complexity" argument, because it actually makes maintenance harder. The more complex your application, you only compound the complexity further by introducing singletons, as it's harder to determine where and when values are set within the application lifecycle. If dependencies are always passed into other objects, you know that the caller is responsible for providing them -- making maintenance and backtracing simpler. The only place where they make sense is when the resource in question is truly singular in nature -- the autoloader is a good example of that. > Let me use Michael's Factory class as an example. Sure, you could > probably rename the class Singleton for clarity. In fact, the > getInstance method could be moved inside the class of the objects > being generated through the Factory class. > > To demonstrate this, you'd create a class called Users that extends > Zend_Db_Table and you'd give it a method called getInstance. Doing > this, you would effectively create a shared resource that serves as a > link to the Users database. Whenever you would use > > $Users = new Users(); > > You could instead use > > $Users = Users::getInstance(); > > That way, instead of reinstantiating an instance of Users all over the > application, you call getInstance and re-use the same object as often > as you'd like - giving the 7X performance boost Michael was > mentioning. That boost can also occur if you simply do metadata caching, per the performance recommendations. ;) Truly, that's the single easiest way to improve performance in Zend_Db_Table, and it has huge impact, particularly if you instantiate multiple copies of the table within your app. Using a singleton for performance reasons is almost always the wrong solution; look instead at how the objects that depend on it get the dependency. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Models as Singletons
On Thu, Jul 23, 2009 at 11:22 PM, Ed Lazor wrote: > I realize some people are saying that Singletons should never be used. > If that's the case, why are they used in Zend Framework? For > example, Zend_Auth, Zend_Registry, Zend_Loader_Autoloader, and > Zend_Controller_Front. Aren't these good examples of where Singletons > are beneficial? It's a trade off between two types of complexity; coupling on one hand and abstraction on the other hand. You don't want coupling, because it makes it hard to reason about your program, but you don't want too much abstraction either. What is "too much" depends a whole lot on the individual programmer, so it can be tricky to pick an appropriate level. There's a certain class of problems where a global symbol doesn't hurt. This is in places where the language imposes global effects in any case. For example, PHP doesn't allow redefining classes, so therefore the autoloader is inherently global in any case. It's not that a global doesn't add coupling here - it's just that the language designers have already made the choice for you. Everything else is a judgement call. > How do you know when it's ok to use Singletons? It seems like > Singletons are beneficial, when used to share a single resource, > because they have the potential for improving performance, and > reducing application complexity. > ... > That way, instead of reinstantiating an instance of Users all over the > application, you call getInstance and re-use the same object as often > as you'd like - giving the 7X performance boost Michael was > mentioning. Now you're mixing apples and oranges again. Global symbols do not improve performance. Shared resources improve performance. Globals are just one way to share resources, but it's not the only one. -- troels
Re: [fw-general] Models as Singletons
Hi, Gladly I did not totally remove my "singleton versions" of my models. I'll see this thread through and decide then what to do with my models. -If there are this performance boost, it's a go-go for singletons -If there are too many (possible) problems, it's a no-go for singletons My models are just shared resources for dealing with some data (DbTables, Acl, Xml or whatever datasource). BUT if I'll go with the singletons, I need to get my head around state-issues on singletons. br, Marko Ed Lazor-3 wrote: > > Since I'm trying to get a better understanding, and since we seem to > be mixing several issues here, let me try to clarify and see if you > agree. > > As per Wiki, a global variable is a variable that is accessible in > every scope They are usually considered bad practice precisely > because of their nonlocality: a global variable can potentially be > modified from anywhere, (unless they reside in protected memory) and > any part of the program may depend on it. A global variable therefore > has an unlimited potential for creating mutual dependencies, and > adding mutual dependencies increases complexity. > > Singletons are considered bad practice, when used as a form of > universal data storage, because, like global variables, they have an > unlimited potential for creating mutual dependencies. > > I realize some people are saying that Singletons should never be used. > If that's the case, why are they used in Zend Framework? For > example, Zend_Auth, Zend_Registry, Zend_Loader_Autoloader, and > Zend_Controller_Front. Aren't these good examples of where Singletons > are beneficial? > > How do you know when it's ok to use Singletons? It seems like > Singletons are beneficial, when used to share a single resource, > because they have the potential for improving performance, and > reducing application complexity. > > Let me use Michael's Factory class as an example. Sure, you could > probably rename the class Singleton for clarity. In fact, the > getInstance method could be moved inside the class of the objects > being generated through the Factory class. > > To demonstrate this, you'd create a class called Users that extends > Zend_Db_Table and you'd give it a method called getInstance. Doing > this, you would effectively create a shared resource that serves as a > link to the Users database. Whenever you would use > > $Users = new Users(); > > You could instead use > > $Users = Users::getInstance(); > > That way, instead of reinstantiating an instance of Users all over the > application, you call getInstance and re-use the same object as often > as you'd like - giving the 7X performance boost Michael was > mentioning. > > And then, adding to the idea a little here, instead of manually adding > the getInstance method to every one of your Zend_Db_Table objects, you > could create a base class with this method that you can extend from. > Or, if you don't have PHP5.3, you can achieve the same thing by using > the Factory class that Michael presented. > > It might seem like a minor adjustment to use a common instance of a > Zend_Db_Table object when working with a specific table throughout > your application. If that 7X performance boost reduces your page load > from 49 seconds to 7 seconds, isn't it worth it? > > Yes - I realize there are other performance enhancements available as > well, cacheing, etc., but this one seems worthwhile also. Or... am I > just barking up the wrong tree and asking for trouble later on? > > Make sense? What do you think? Matthew? > > -Ed > > -- View this message in context: http://www.nabble.com/Models-as-Singletons-tp24575704p24639257.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Models as Singletons
Since I'm trying to get a better understanding, and since we seem to be mixing several issues here, let me try to clarify and see if you agree. As per Wiki, a global variable is a variable that is accessible in every scope They are usually considered bad practice precisely because of their nonlocality: a global variable can potentially be modified from anywhere, (unless they reside in protected memory) and any part of the program may depend on it. A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity. Singletons are considered bad practice, when used as a form of universal data storage, because, like global variables, they have an unlimited potential for creating mutual dependencies. I realize some people are saying that Singletons should never be used. If that's the case, why are they used in Zend Framework? For example, Zend_Auth, Zend_Registry, Zend_Loader_Autoloader, and Zend_Controller_Front. Aren't these good examples of where Singletons are beneficial? How do you know when it's ok to use Singletons? It seems like Singletons are beneficial, when used to share a single resource, because they have the potential for improving performance, and reducing application complexity. Let me use Michael's Factory class as an example. Sure, you could probably rename the class Singleton for clarity. In fact, the getInstance method could be moved inside the class of the objects being generated through the Factory class. To demonstrate this, you'd create a class called Users that extends Zend_Db_Table and you'd give it a method called getInstance. Doing this, you would effectively create a shared resource that serves as a link to the Users database. Whenever you would use $Users = new Users(); You could instead use $Users = Users::getInstance(); That way, instead of reinstantiating an instance of Users all over the application, you call getInstance and re-use the same object as often as you'd like - giving the 7X performance boost Michael was mentioning. And then, adding to the idea a little here, instead of manually adding the getInstance method to every one of your Zend_Db_Table objects, you could create a base class with this method that you can extend from. Or, if you don't have PHP5.3, you can achieve the same thing by using the Factory class that Michael presented. It might seem like a minor adjustment to use a common instance of a Zend_Db_Table object when working with a specific table throughout your application. If that 7X performance boost reduces your page load from 49 seconds to 7 seconds, isn't it worth it? Yes - I realize there are other performance enhancements available as well, cacheing, etc., but this one seems worthwhile also. Or... am I just barking up the wrong tree and asking for trouble later on? Make sense? What do you think? Matthew? -Ed
Re: [fw-general] Models as Singletons
When you see a method called getInstance(), is it assumed to be a singleton
class. I don't think non singleton classes use or need to have a method
called getInstance(). What are you trying to achieve with a static function
that returns a new instance of the class that you can not or don't want to
achieve by just creating a new instance as in "$instance = new SomeClass;" ?
On Tue, Jul 21, 2009 at 10:38 PM, Marko Korhonen <
marko.korho...@datafisher.com> wrote:
>
> Hi,
>
> Here's my original method:
> public static function getInstance()
>{
>if (null === self::$_instance) {
>self::$_instance = new self();
>}
>
>return self::$_instance;
>}
>
> and I changed it to:
>
> public static function getInstance()
>{
>return new self();
>}
>
> Maybe the method name still implies to singleton?
>
> Marko
>
>
> Peter Warnock-2 wrote:
> >
> > On Tue, Jul 21, 2009 at 10:53 AM, Marko Korhonen <
> > marko.korho...@datafisher.com> wrote:
> >
> >>
> >> Thanks fo everybody for the great comments!
> >>
> >> I decided to change my getInstance() method so it just
> >> created new instance of the class and returns it (giving up on singleton
> >> on this case).
> >>
> >> So if I have static call:
> >> $model = Comment_Model_Comment::getInstance();
> >> it's the same if I would write:
> >> $model = new Comment_Model_Comment();
> >>
> >> Only difference being that I can call directly some methods like:
> >> $comments = Comment_Model_Comment::getInstance()->getAll();
> >>
> >> Any considerations to this one?
> >>
> >> getInstance implies it is a Singleton. You are describing a factory
> >> method.
> >
> > - pw
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Models-as-Singletons-tp24575704p24595370.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
>
Re: [fw-general] Models as Singletons
Hi,
Here's my original method:
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
and I changed it to:
public static function getInstance()
{
return new self();
}
Maybe the method name still implies to singleton?
Marko
Peter Warnock-2 wrote:
>
> On Tue, Jul 21, 2009 at 10:53 AM, Marko Korhonen <
> marko.korho...@datafisher.com> wrote:
>
>>
>> Thanks fo everybody for the great comments!
>>
>> I decided to change my getInstance() method so it just
>> created new instance of the class and returns it (giving up on singleton
>> on this case).
>>
>> So if I have static call:
>> $model = Comment_Model_Comment::getInstance();
>> it's the same if I would write:
>> $model = new Comment_Model_Comment();
>>
>> Only difference being that I can call directly some methods like:
>> $comments = Comment_Model_Comment::getInstance()->getAll();
>>
>> Any considerations to this one?
>>
>> getInstance implies it is a Singleton. You are describing a factory
>> method.
>
> - pw
>
>
--
View this message in context:
http://www.nabble.com/Models-as-Singletons-tp24575704p24595370.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Models as Singletons
On Tue, Jul 21, 2009 at 8:31 PM, Matthew Weier O'Phinney wrote: > -- Ed Lazor wrote > (on Tuesday, 21 July 2009, 11:03 AM -0700): >> On Tue, Jul 21, 2009 at 10:48 AM, troels knak-nielsen >> wrote: >> > Irey wrote: >> >> That's a performance boost of 7X using a singleton versus not using a >> >> singleton. >> > >> > You're conflating two unrelated concepts. The performance difference >> > that you observe is due to the difference between instantiating a new >> > object per iteration vs. reusing the same. >> >> Isn't that one of the benefits of using a singleton? > > No, that's a performance benefit of re-using the same object. You can > achieve the same benefit by passing the object in as a dependency to > another object. > Speaking of "DI" (Dependency Injection), this is an interesting read: http://www.whitewashing.de/blog/articles/118 Till
Re: [fw-general] Models as Singletons
-- Ed Lazor wrote (on Tuesday, 21 July 2009, 11:03 AM -0700): > On Tue, Jul 21, 2009 at 10:48 AM, troels knak-nielsen > wrote: > > Irey wrote: > >> That's a performance boost of 7X using a singleton versus not using a > >> singleton. > > > > You're conflating two unrelated concepts. The performance difference > > that you observe is due to the difference between instantiating a new > > object per iteration vs. reusing the same. > > Isn't that one of the benefits of using a singleton? No, that's a performance benefit of re-using the same object. You can achieve the same benefit by passing the object in as a dependency to another object. > > You can reuse the same object in other ways than through a global symbol. > > Aren't singleton classes preferred over global variables? Yes, but only slightly. A singleton is still a global container of sorts. The main difference is that it's namespaced. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Models as Singletons
On Tue, Jul 21, 2009 at 10:53 AM, Marko Korhonen < marko.korho...@datafisher.com> wrote: > > Thanks fo everybody for the great comments! > > I decided to change my getInstance() method so it just > created new instance of the class and returns it (giving up on singleton > on this case). > > So if I have static call: > $model = Comment_Model_Comment::getInstance(); > it's the same if I would write: > $model = new Comment_Model_Comment(); > > Only difference being that I can call directly some methods like: > $comments = Comment_Model_Comment::getInstance()->getAll(); > > Any considerations to this one? > > getInstance implies it is a Singleton. You are describing a factory method. - pw
Re: [fw-general] Models as Singletons
On Tue, Jul 21, 2009 at 8:03 PM, Ed Lazor wrote: > On Tue, Jul 21, 2009 at 10:48 AM, troels knak-nielsen > wrote: >> Irey wrote: >>> That's a performance boost of 7X using a singleton versus not using a >>> singleton. >> >> You're conflating two unrelated concepts. The performance difference >> that you observe is due to the difference between instantiating a new >> object per iteration vs. reusing the same. > > Isn't that one of the benefits of using a singleton? Yes, that's one of them. A big problem with singleton is that it does two things. One one hand, it ensures a single instance in the application, and on the other hand it provides a means to share this instance. Those two things do not need to be coupled together. >> You can reuse the same object in other ways than through a global symbol. > > Aren't singleton classes preferred over global variables? Most people would say that, yes. And I agree, but I would really prefer neither. Global variables and singletons and static methods and static variables all share a similarity in that they are globally scoped symbols. That makes all of them suspect. -- troels
Re: [fw-general] Models as Singletons
On Tue, Jul 21, 2009 at 10:48 AM, troels knak-nielsen wrote: > Irey wrote: >> That's a performance boost of 7X using a singleton versus not using a >> singleton. > > You're conflating two unrelated concepts. The performance difference > that you observe is due to the difference between instantiating a new > object per iteration vs. reusing the same. Isn't that one of the benefits of using a singleton? > You can reuse the same object in other ways than through a global symbol. Aren't singleton classes preferred over global variables? -Ed
Re: [fw-general] Models as Singletons
On 21 Jul 2009, at 18:49, till wrote: Generally, what Matthew stated is super-correct. The singleton makes testing harder, as does everything static because it's hard to "reset" the state. People use singletons because the so-called business logic demands, or more often because they are not very skilled programmers. ;-) (No offense meant!) None taken ;-) I'm definitely not a very skilled programmer but I'd argue that using singletons can just be a case of getting on with the job at hand. Even accepting that it makes testing harder, using singletons can be simpler overall. In particular, in relatively small applications with a known scope/ domain (the average professional PHP developer's bread-and-butter) knocking up a singleton version of key resources (those that may be needed anywhere) is so quick and easy that the trade off against some shared fixtures in the test suite is no problem. Regards, Carlton
Re: [fw-general] Models as Singletons
Thanks fo everybody for the great comments! I decided to change my getInstance() method so it just created new instance of the class and returns it (giving up on singleton on this case). So if I have static call: $model = Comment_Model_Comment::getInstance(); it's the same if I would write: $model = new Comment_Model_Comment(); Only difference being that I can call directly some methods like: $comments = Comment_Model_Comment::getInstance()->getAll(); Any considerations to this one? br, Marko troels knak-nielsen-2 wrote: > > On Tue, Jul 21, 2009 at 1:52 PM, Marko > Korhonen wrote: >> - Is there performance gain or memory savings or something like that? > > On the contrary. A singleton prevents the garbage collector from > functioning. > >> - Code syntax benefits? > > That's rather subjective. > >> - Something else? > > Low level of abstraction means easy to understand. This is the only > benefit of a singleton. While it's real, it usually doesn't make up > for the high level of coupling it incurs. Ultimately it's a judgement > call, but most experienced programmers wouldn't use them in this > scenario (or at all). > >> Only thing I really understand that it gets always the same instance of >> the >> class >> and does not create new ones. > > If you don't fully understand the implications of singletons, you > should probably avoid them like the plague. If you *do* understand the > implications of singletons you *will* avoid them like the plague. > > -- > troels > > -- View this message in context: http://www.nabble.com/Models-as-Singletons-tp24575704p24592194.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Models as Singletons
On Tue, Jul 21, 2009 at 7:43 PM, Michael Irey wrote: > > On 7/21/09 4:52 AM, "Marko Korhonen" wrote: >> - Is there performance gain or memory savings or something like that? > > I don't remember who, but someone on ZFChat had recommended using Factory > for zend_db_table objects to give a performance boost on the application. > After reading this thread, we ran a few tests to see what the actual > performance boost is and it does seem significant. > > Here is what we are using for our Factory: > http://pastie.org/553707 http://en.wikipedia.org/wiki/Singleton_pattern What you have a is a singleton. A factory pattern is used to create objects, see here: http://en.wikipedia.org/wiki/Factory_method_pattern Generally, what Matthew stated is super-correct. The singleton makes testing harder, as does everything static because it's hard to "reset" the state. People use singletons because the so-called business logic demands, or more often because they are not very skilled programmers. ;-) (No offense meant!) There are other ways to make sure you are only using a single instance of the same object. Forcing the same behaviour in code is absurd because that means that you're working around of the short comings of the people using it. The performance gain in your example comes from re-using the object. Not from using a design pattern. Till
Re: [fw-general] Models as Singletons
On Tue, Jul 21, 2009 at 7:43 PM, Michael Irey wrote: > That's a performance boost of 7X using a singleton versus not using a > singleton. You're conflating two unrelated concepts. The performance difference that you observe is due to the difference between instantiating a new object per iteration vs. reusing the same. You can reuse the same object in other ways than through a global symbol. -- troels
Re: [fw-general] Models as Singletons
On 7/21/09 4:52 AM, "Marko Korhonen" wrote: > - Is there performance gain or memory savings or something like that? I don't remember who, but someone on ZFChat had recommended using Factory for zend_db_table objects to give a performance boost on the application. After reading this thread, we ran a few tests to see what the actual performance boost is and it does seem significant. Here is what we are using for our Factory: http://pastie.org/553707 Here's the code: Singleton: http://pastie.org/553697 Non-Singleton: http://pastie.org/553702 And here's the test results: Singleton:0m2.163s Non-Singleton:0m15.708s That's a performance boost of 7X using a singleton versus not using a singleton. There are times where singletons are beneficial. After all, they are used by ZF. It also seems like it's easy to add a method to reset the instance in the factory, which you'll see in the Factory code listed above. Do you think is a good example of when to use singleton's? Does this seem to still go against best practices? I'm trying to get a better understanding of why more experienced programmers don't use them. Matthew, could you describe in more detail the problems you were running into with Unit Testing? Anything else we could be overlooking? -Michael
Re: [fw-general] Models as Singletons
Marko Korhonen a écrit : Ok, I might live with that. So what are the main pros using singletons? - Is there performance gain or memory savings or something like that? - Code syntax benefits? - Something else? You don't use singleton for performance or whatever, you use singleton because that's what your buisness model tell you. For more information you can look at the GOF book page 127. Only thing I really understand that it gets always the same instance of the class and does not create new ones. br, Marko Matthew Weier O'Phinney-3 wrote: -- Marko Korhonen wrote (on Monday, 20 July 2009, 12:06 PM -0700): I made my Model classes singletons and I'm wondering if there is any major cons in this solution. One major one: Testing. I've had to do a lot of testing against singletons, and it's simply not worth it. It requires hacks for resetting state, and when you have a test suite where these objects may be used in a number of different suites, state becomes a tricky proposition. Here's my setup from one on the modules: Comment_Model_Comment (Model Comment from Comment module, Singleton) Comment_Model_DbTable_Comment (Zend_Db_Table extended class) Comment_Model_DbTable_Rowset_Comment (Zend_Db_Table_Rowset extended class) Comment_Model_DbTable_Row_Comment (Zend_Db_Table_Row extended class) So I made my Model class as singleton becouse it does not represent individual comments. It's just one class knowing what to do with comments. I tried to avoid having too many instances of this model class for vain. Any comments or questions ? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ -- -- Mathieu Suen --
Re: [fw-general] Models as Singletons
I might live with that. So what are the main pros using singletons? - Is there performance gain or memory savings or something like that? For all intents and purposes, no. Especially since you are in the web environment, application runtime is extremely short (on the order of the length of a single request). At the end of every request, memory and resources are unloaded (this is what is called as a shared-nothing architecture). - Code syntax benefits? You get a single name based container for free (a singleton is basically both a factory and a registry). Of course, this has to line up with your application goals, and/or your libraries overall code perspective. - Something else? If you are gonna use them, especially in a library, practice good developer citizenship. If you write a getInstance() method, also remember to write a resetInstance() method. Any stateful information that is statically tracked by the class, should be able to be reset when asked to. -ralph
Re: [fw-general] Models as Singletons
On Tue, Jul 21, 2009 at 1:52 PM, Marko Korhonen wrote: > - Is there performance gain or memory savings or something like that? On the contrary. A singleton prevents the garbage collector from functioning. > - Code syntax benefits? That's rather subjective. > - Something else? Low level of abstraction means easy to understand. This is the only benefit of a singleton. While it's real, it usually doesn't make up for the high level of coupling it incurs. Ultimately it's a judgement call, but most experienced programmers wouldn't use them in this scenario (or at all). > Only thing I really understand that it gets always the same instance of the > class > and does not create new ones. If you don't fully understand the implications of singletons, you should probably avoid them like the plague. If you *do* understand the implications of singletons you *will* avoid them like the plague. -- troels
Re: [fw-general] Models as Singletons
Ok, I might live with that. So what are the main pros using singletons? - Is there performance gain or memory savings or something like that? - Code syntax benefits? - Something else? Only thing I really understand that it gets always the same instance of the class and does not create new ones. br, Marko Matthew Weier O'Phinney-3 wrote: > > -- Marko Korhonen wrote > (on Monday, 20 July 2009, 12:06 PM -0700): >> I made my Model classes singletons and I'm wondering if there is any >> major >> cons in this solution. > > One major one: Testing. > > I've had to do a lot of testing against singletons, and it's simply not > worth it. It requires hacks for resetting state, and when you have a > test suite where these objects may be used in a number of different > suites, state becomes a tricky proposition. > >> Here's my setup from one on the modules: >> Comment_Model_Comment (Model Comment from Comment module, Singleton) >> Comment_Model_DbTable_Comment (Zend_Db_Table extended class) >> Comment_Model_DbTable_Rowset_Comment (Zend_Db_Table_Rowset extended >> class) >> Comment_Model_DbTable_Row_Comment (Zend_Db_Table_Row extended class) >> >> So I made my Model class as singleton becouse it does not represent >> individual comments. >> It's just one class knowing what to do with comments. >> >> I tried to avoid having too many instances of this model class for vain. >> >> Any comments or questions ? > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ > > -- View this message in context: http://www.nabble.com/Models-as-Singletons-tp24575704p24586221.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Models as Singletons
-- Marko Korhonen wrote (on Monday, 20 July 2009, 12:06 PM -0700): > I made my Model classes singletons and I'm wondering if there is any major > cons in this solution. One major one: Testing. I've had to do a lot of testing against singletons, and it's simply not worth it. It requires hacks for resetting state, and when you have a test suite where these objects may be used in a number of different suites, state becomes a tricky proposition. > Here's my setup from one on the modules: > Comment_Model_Comment (Model Comment from Comment module, Singleton) > Comment_Model_DbTable_Comment (Zend_Db_Table extended class) > Comment_Model_DbTable_Rowset_Comment (Zend_Db_Table_Rowset extended class) > Comment_Model_DbTable_Row_Comment (Zend_Db_Table_Row extended class) > > So I made my Model class as singleton becouse it does not represent > individual comments. > It's just one class knowing what to do with comments. > > I tried to avoid having too many instances of this model class for vain. > > Any comments or questions ? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
[fw-general] Models as Singletons
Hi, I made my Model classes singletons and I'm wondering if there is any major cons in this solution. Here's my setup from one on the modules: Comment_Model_Comment (Model Comment from Comment module, Singleton) Comment_Model_DbTable_Comment (Zend_Db_Table extended class) Comment_Model_DbTable_Rowset_Comment (Zend_Db_Table_Rowset extended class) Comment_Model_DbTable_Row_Comment (Zend_Db_Table_Row extended class) So I made my Model class as singleton becouse it does not represent individual comments. It's just one class knowing what to do with comments. I tried to avoid having too many instances of this model class for vain. Any comments or questions ? br, Marko -- View this message in context: http://www.nabble.com/Models-as-Singletons-tp24575704p24575704.html Sent from the Zend Framework mailing list archive at Nabble.com.
