Re: Concepts I'm still not sure of...

I did exactly the same application couple of years ago. Everything was in models and controllers. Models like: Item, Order, Stock, Delivery_price, Delivery_zone, Invoice, etc... The bigest was OrderModel with 1300 lines and the same for the OrdersController. In total 24 Models but it includes everything: logistics, distributors, artists, promos, gifts, royalties, collections, users, clients, mailings, invoices, reminders, etc., etc... I don't really see the need for 50 models.

On Monday, June 25, 2012 2:22:49 AM UTC+2, godjen99 wrote:

So I have been working with CakePHP a while now, and feel pretty comfortable with it. I get the common ideas of MVC, but recently ran into a situation at work that I can't put my finger on how to tackle. The company I work for wants to build a very large application that consists of many procedures when something takes place. So I'll use an website that sells things as an example to try to illustrate the issues I'm seeing.

When someone orders an item, many things happen. For example, the item is removed from the inventory. Then the inventory is then checked to see how low it is, if it's too low then an email fires off to the company telling of the issue. The order is them charged to the customer and the order's status is set to be "shipped", which another department monitors.

Later in the item's life cycle, the order's status is set to "completed" and a list of things happen, making up another process.

So here's the problems I'm facing. Should I store this logic in a behavior, a component or a model? I'm afraid of the model getting too fat. I can see MANY functions being built in the model, which would then make for a messy model; only in the sense of size (3000 lines or more), not the actual code.

So some of the ideas kicked around is putting them in a behavior (which I'm not sure if that kind of logic would go there as it's coupled to the Item model only), or maybe in a component that relies on models (which I think breaks Cake's convention), or in custom vendor classes or maybe even making pseudo models for functionality. For example there's an Item model, then a ShippedItem model and maybe a CompletedItem model, with the thought being the logic behind getting any of those things would be stored in it's own model versus the Item model holding the logic for getting a shipped, completed and un-ordered item. I'm shooting for logic separation and a loose coupling as possible. 

Moreover, I'm trying to think of where the code that would be called to execute all the separate processes would go. For example, when I want to "ship an item by ID" (taking a single item and doing all the steps needed to make it "shipped"), I'm not sure wehre to put the "main" function that would call all the sub-functions to make that process.

I'm very open to suggestions and would love to hear some feed back. 

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php