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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
