A quick question

[Waseem Hamshawi]

Hi All,
When using modules, where do you think it's better to store models? inside module's models folder or in /protected/models ?
i.e : I have a project module which contain Project model... but the Sitecontroller (which is out of the module) needs also to use this model inorder to display latest projects..
I'm currently placing the module's model inside the module's folder, but I was thinking about the second approach today and it sounds more logical..

what do you think? :)

[Boaz Rymland]

I think that answer is clear - the module's models should be under the module's folder. 

I see little justification for not doing so. that's modularity, loose coupling and possibly several other important design principals that's backing this up. 

If you start to couple, bind, and inter connect components in the system you loose its modularity and lots of other OOD benefits. Soon, you'll get to one class/controller peeking and using other class methods/properties, starting to "know" about other classes internals and you're next stop is a few months down the road, trying to figure how to untangle this mess/spaghetti-code... .

Ok, you might say, "so I'll take it. What do I do with siteController that needs to use this Model class?". If your application must be using that module that's fine - make a check in its beginning and "complain" as you see fit (error 500, 400, whatever fits this best for you). Also, here's comes into play my lack of knowledge in design patterns. From what I know, how about having some component (in protected/components) that serve as a "factory" for the needed model? Maybe have some abstract class in the application level (component as well) and that module would extend (or implement, in case of an interface) it? (that of course requires considering the changes on the module's end). this factory will contain the knowledge about that module, check if it exists, complain if not, possibly instantiate some substitute class, etc.  siteController should be (highly) preferably not binded to the module's model class. 

I hope this contributes... .

Boaz.

--
You received this message because you are subscribed to the Google Groups "Yii ישראל (Israel)" group.
To view this discussion on the web visit https://groups.google.com/d/msg/yii-israel/-/DDoH8Smio-kJ.
To post to this group, send email to yii-i...@googlegroups.com.
To unsubscribe from this group, send email to yii-israel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/yii-israel?hl=en.

[Waseem Hamshawi]

actually this dilemma raised up when I finished developing the project's module and went to the main dashboard (i.e SiteController)..
You're right, the sitecontroller doesn't use the model extensively and the "trace" after whether the module and its models exist isn't a big footprint over the controller's code. it can be handled by a small component which checks for module id and throws exception in the worst case.
Factory pattern can serve as an approach for implementing this component. I'll look into that indeed.
And I'll stick to my current models placement.. what a comfort :)

By the way, A favorite approach that I learned and I'm implementing, is to create a separate folder for model's business logic methods. i.e for Project model create ProjectBL class which includes all model's methods that are concerned with the business logic of the model. A thumb rule i'm following is that methods with over 7 lines in the model, should be moved to BL class.

[Boaz Rymland]

about that last comment - so you mean that relations(), rules() etc are kept in the model class file but the biz logic methods are taken out? 

If so, it sounds interesting but I'm not so sure that its really needed if you have a decent IDE. with an IDE, I don't need to bother remember where at all the methods are. I just popup the "goto method box" and start typing... . very fast, very convenient, very safe.

[Waseem Hamshawi]

it's actually an extra layer to "thin" the model class (which can be huge in medium/large projects)... Good IDE should not justify not improving system's design and logic (i'm speaking generally).

[Boaz Rymland]

Ok. might be useful some day :-) 

(and I agree that generally speaking, design of files should be regardless of IDE considerations, generally speaking).