1

I am trying to develop my first major MVC application, and as such I am new to doing this on a large scale. I've read as much as I can online and am continuously striving for making my code as clean as possible and not introduce any bad practices. Right now, I'm starting to question if my setup is the way it would be done in the real world.

Right now, I have my main container class and sub classes that can appear inside.

Lets pretend the view would look like this:

-----------------------------------------------------
|                                                   |
|                    Main    |-----------------|    |
|   |------|                 |D |-----------|  |    |
|   |  A   |                 |  |  B  |  C  |  |    |
|   |      |                 |  |     |     |  |    |
|   |------|                 |  |-----------|  |    |
|                            |-----------------|    |
-----------------------------------------------------

Where Main is your main viewing container, and inside are elements A, B and C.

The inner views can be dynamic, so lets say we have our own MVC's for A, B and C as well.

1) Is it wrong for these classes to be connected to one other like so?

     /------A
    /
Main
    \         /-B
     \       /
      \-----D---C

By this, I mean both connections are two way. To get to 'A' from B, I might call something like this.getD().getMain().getA() from object C.

Does that indicate a design problem if it's a web where things can traverse back and forth?

Is there any bad practice of passing it object A so the chain doesn't have to be done?

This can assume there is no nulls for the sake of this example

2) If the above is not okay, is it unreasonable to make a static singleton out of the Main object and have other classes access it through a static getter?

I don't know if such a practice is bad or not if you know the main window is never meant to be instantiated twice (and you prevent it from doing so). An example would be to get A from C, something like Main.getA().

I apologize if some of this is vague. As I said I'm new to this and would love nothing more than to cut out any bad habits. If there is anything wrong or right about what I've done? If there's anything wrong, how would you do it?

  • Are those classes your view or your model? In the former case, I don't think they should even know each other (if not for layout purposes), in the latter, their relations should just fit the business logic. Also be aware that what you're doing sounds like a variation of mvc called Hierarchical MVC. – bigstones Feb 21 '15 at 7:06
2

Just some thoughts, continue to do your research on best practices. First, respect encapsulation and avoid tight coupling between views. Consider using dependency injection to inject inner views into outer views in your hierarchy - or decorating, etc. depending on the use-case.

Is there a specific functional reason you want two-way chainable calling between the view components? If you want to know whether you are doing the right thing, ask yourself what the use-case is. Let's say you have a visible counter in A that increments/decrements based on data changing in C. Is there a reason for A (a counter control) to know anything about C (some kind of data entry control)? No.

For communication in this case, you should use an event model where changing data in C fires an event that is picked up by the controller, which then updates the model with the new counter value. The model variable for the count should be data-bound to the control A. When the event fired from C updates the model, control A's value changes. C is informing the application of the data used by A, but A has no knowledge of C, its structure or its methods.

Reading about patterns in OOP and MVC will help you.

Specific questions like making a Singleton out of Main really depend on the specifics of your app.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.