[Catalyst] Re: MVCR pattern

[David Storrs]

On Aug 11, 2005, at 10:17 AM, Christopher H. Laco wrote:

> David Storrs wrote:
>
>> Let's say you  define your generic ShoppingCart.pm module. Some  
>> part of your MVC app  needs to know which functions to call in  
>> ShoppingCart.pm--what I've  been talking about is what part that  
>> should be, the M or the C.
>> --Dks
>>
>
> IMHO, Model. Maybe today it's ShoppingCart.pm...maybe next month  
> it's NewImprovedShoppingCart.pm. Assuming the APIs have changed,  
> you wouldn't want to have to go around changing controllers; you  
> would just change or rewrap the method name in the Model.

Well, ok.  I don't see any gain there--you're just saying "I'd rather  
change the model than the controller", but whatever.  To me, a gain  
would be if you could demonstrate that you /wouldn't need/ to change  
the model.


> That does bring up the question of preparedness vs. to much work.

IME, always DTSTTCPW (Do The Simplest Thing That Could Possibly  
Work).  95+% of the time you never need the extra functionality.   
(And, of course, 78.2% of all statistics are made up on the spot.)


> Should the ShoppingCartModel in this case have it's own methods  
> wrapping the ShoppingCart.pm methods...a duplication of code, but a  
> true seperation in case of change. Or is ShoppingCartModel use- 
> basing ShoppingCart.pm enough for now?

Personally, I would do the latter.  The first time that you really,  
really need to break the API and there is no way around it is the  
justification for refactoring your other apps.

--Dks