Stephan van Hulst wrote:When you need a class that takes care of certain responsibilities, you should ideally give them all the information they need and nothing more.
If your GuitarModel requires a ChordManager, then pass one to it in the constructor. The same goes for your EditChordModel.
"In our example the model layer includes the Book class. In a real scenario, the model will include all the entities and the classes to persist data into the database, and the classes encapsulating the business logic."
Does this mean that each method that is being required from the Controller has to be implemented in one Model.
Stephan van Hulst wrote: If you explain more about what you want your program to do, we can advise you on the buildup of it.
Neil Cartmell wrote:That's the basics. Sorry if that was too much info. I know it will be hard to know what the hell I'm talking about. I've tried to make it as clear as I can though.
Neil Cartmell wrote:I know I could get it working dead easy, but trying to find out if it's considered good programming practice is very hard.
Winston Gutkowski wrote:
PS: It occurred to me that you might be confusing multiple 'Model' classes with multiple Models; they're not (or not generally, anyway). They're all regarded as part of the same Model, and are often in same package too. Major components (as, in your case, a Guitar) may well have a 'triad' of classes; one for each part of the system.
Neil Cartmell wrote:Yes I think this was part of the confusion. I see model written and it's always written as if there is some Model class that contains all the other models, and I was confused as how that should work. All the examples I am seeing set up the controller and view with one model class, and I'm left wondering is it ok to make the controller create the other model classes or do I pass multiple model classes into the controller.
Neil Cartmell wrote:All the examples I am seeing set up the controller and view with one model class, and I'm left wondering is it ok to make the controller create the other model classes or do I pass multiple model classes into the controller.
Neil Cartmell wrote:Thanks. A lot of useful information but I'm still not quite getting it...
Neil Cartmell wrote:"I think the controller is supposed to choose the correct model and give it to the view. "
I appreciate all the help and hope I don't comes across as ungrateful but the answers I was looking for seem so simple. I just needed a starting point, a basic example on how to set up a program with multiple vies, controllers or models...
Neil Cartmell wrote:Well after hours and hours of trying to find out what object is supposed to create what other object in MVC I saw this posted in a comment.
"I think the controller is supposed to choose the correct model and give it to the view. "
"I agree with Yogler, the controller sets up the models needed then passes them onto the view regardless of how many there are. "
That's good enough for me; the word Model that ends with 's'. My application controller will now set up the various models. That's all I needed, or wanted to know. And if someone comes along and says "no no no you should never do that" I will likely walk away from design patterns forever because there seems to be some rule that stops any object from creating another or knowing about another but never a straight forward answer to what should be done instead.
Well after hours and hours of trying to find out what object is supposed to create what other object in MVC I saw this posted in a comment.
Dennis Deems wrote:
I thought your first couple of examples were just fine. What worried you about them? Whenever I have used MVC, some higher-level class created the Model and the View and then passed them into the constructor of the Controller.