I can't say what is best practice, but here are things that I've done in the past.
Regards
On Sunday, 13 October 2013 23:49:14 UTC+10, acl68 wrote:
-- Putting in a component:
For a little bit, I was shoving things that did not need to be directly in the Model, into a component. This is great, as long as you only need to access that logic from a Controller. However, if the existing logic is already in a Model, and you want to move it out, then I would not suggest the component. For me, the Component is about subtlely changing the behavior of the controller, making use of startUp, shutdownDown and the lifecycle flow. If the logic doesn't have anything to do with lifecycle of the controller, then I wouldn't bother putting it in the component.
Putting in a lib:
My next pattern was putting functionality into a Lib/* directory. I was particularly fond of doing this for SOAP Web Services. The controller would still call a model, but then the model would call the Web Service to perform SOAP call. The advantage was that these Web Service libraries would be available from controllers and components as well.
My 2 cents. Go nuts with the structure if your app.
If you have an obese model that is filled with helper functions that don't directly need services provided by the model, don't be afraid to add structure that suites you. I would create a ModelHelper directory, and then create model helper classes that the model would call as required.
i.e.
Model/MyObeseModel.php
ModelHelper/MyObeseModelHelper.php
and in MyObeseModel.php
App::uses('MyObeseModelHelper', 'ModelHelper');
Then you can create a new instance of MyObeseModelHelper as you need it, or instantiate it in the constructor, so it's always available. If they're really helper methods, you might get away with having them be static, and pass the model in.
At least by using ModelHelper, you avoid a Lib directory that could get filled with all sorts of cruft, and know that ModelHelper contains helpers for models. You could go one step further have have Model\Helper\MyObeseModelHelper.php. I think that might be possible with CakePHP 2.x and the App::uses() clause, and would probably do rather well in CakePHP 3.0, when we can start using namespaces properly.
This might not be the best way, but it's a way, and I'd also love to hear if anyone else has a recommendation or two.
Regards
Reuben Helms
On Sunday, 13 October 2013 23:49:14 UTC+10, acl68 wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everybody,
I have a slightly advanced question.
I just build an app which at some point goes through a lot of evaluation
methods to find a certain value in a heap of values.
I want to follow the fat model theory also because it makes methods
easier for unit tests.
Now my model shows a tendency to not only become fat, but obese and I
consider putting the advanced logic in another place. The question is:
What could that be?
Normally I would create models which would extend my obese model and
place the methods there so they are out of the way. But most of these
methods don't need direct dealing with the database so I could just put
them elsewhere shuffle data in and get the output out after they went
though this "black evaluation box".
Would a component be this place? Or a model without db table?
What would be the professional CakePHP way of doing this?
Thanky for any hints in advance as always!
Anja
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlJapNoACgkQbOdiIJzHNKFhRQCfUvyum1yGptJwp8gmVMSM /p/5
GCEAoIVWHP4q2aZhsZGLXbsGVucJ+1DW
=OcX6
-----END PGP SIGNATURE-----
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP
---
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscribe@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment