A typical way to solve the website order problem is that you have Models for logical grouping of data with relationships (belongsTo, hasmany, HABTM, etc) between these models. For example, I would have a products model, for list of products for sale; an inventory model, for current inventory, price, shipping, etc; an order model, for orders; an orderItem model, for a list of items per order; a customer model; Just to name a few. Depending on the complexity, this could easily get to 20, 30 or 100 models. All of these specific, so you don't have 1-2 model trying to do everything.
The controllers then take the actions for the users and use the models to update their data. Things like, changing inventory counts, or adding orders, updating order status, from pending, processing, shipped, delivered, etc.
The views and the controllers can also provide different looks at the data based on the role of the user. The person placing the order can see some information about the order, price, etc. But, the shipping department may only see details about the order need to pack and ship. They don't need to see price. The sales department may see price, qty and other information to help place orders.
If you lay out the data correctly, I would expect to see more small to medium size models, rather than a few large ones. Because if you think about it, you don't need to copy the data for each different group. Just give them a different view of the parts they need to do their job.
my $0.02.
bill
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
[hidden email] For more options, visit this group at http://groups.google.com/group/cake-php
If you reply to this email, your message will be added to the discussion below:http://cakephp.1045679.n5.nabble.com/Concepts-I-m-still-not-sure-of-tp5708990.htmlTo start a new topic under CakePHP, email [hidden email]
To unsubscribe from CakePHP, click here.
NAML
View this message in context: Re: Concepts I'm still not sure of...
Sent from the CakePHP mailing list archive at Nabble.com.
--
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
No comments:
Post a Comment