MVC Refactor, Take 2

[s_molinari]

I am really glad you are open to the direction I’m looking at.

@TomB

This is an interesting approach but having the model decode the URL does feel like mixing responsibilities to me

There definitely needs to be a logic for taking the purpose of the intended web page request and turning it into a correct output. Let’s not call it “URL decoding” or even a router/ controller mix, but application processing logic or workflow logic. It is the model of how the application/ framework works internally. I’d say this needs a real home too. Putting it in a router and then using the resulting parameters from the Request and the Router (objects) in a controller, the model and/ or the View is splitting the processing workflow out into 4 different areas. That, to me, avoids KISS.

The fact I have called for the application processing logic in the Model is only because I feel that is the right time to call it. But, theoretically, the application processing logic can be called to be built anywhere after the Request object is built.

I’d like to point out too, the “decoded URL” logic, as you called it, or rather the application processing logic, as I’d call it, is also needed, in most cases, in the View, which, according to the definition of MVC, should get its application state and data from the model. This is another reason for why I felt the call to build the application processing logic needs to be done in the Model.

LOL! Now we are sort of getting into the realm of Tony’s argument. Is a model class that calls on the object to build application workflow logic (along with data and state) AND building the client’s Model (along with data and state) doing too much? I’d say no. Because, the definition of MVC calls for it. The base Model Class will need to do even more actually, like validation and authorization. However, it shouldn’t all be done in the single class, but through a good number of sibling classes (which can also be extended), from which the Model will get its functionality.

@TomB

the model is now making decisions about the application flow based on the path. Personally I’d split that into two different classes (because then you could have both the NTP model and normal model in different classes with the same interface)… effectively reintroducing a router. However, what I like about this is that it’s not a centralised routing table, each MVC triad has its own set of routes and makes its own decisions.

Absolutely and the actual beauty of the idea of doing a whole lot more, practically everything, in the model (and doing the absolute minimum, practically nothing, in the controller). This is what you opened my eyes to. The clock model can easily be refactored into separate classes, without having to duplicate any code. Doing the same with a router would be very close to duplicated code.

@TomB

This should almost certainly be an interface rather than a class. Let the application developer implement the interface rather than having these wrapper methods that don’t really do anything.

Agreed. I was thinking the whole time the client Model would need to follow a certain pattern/ interface, and I am going to be totally honest and say, I actually am not completely sure how to implement it properly. I am most definitely playing the student role here and am loving it! Thanks for taking the time to teach and discuss the alternatives. I hope Jeff isn’t terribly upset with me working in my ideas here too.

Scott