Re: Code Conflation: Considered Harmful?

I wish somebody had commented on who the "sage" was you refer to. I would like more reading on this subject.

I have seen functional programming come up a few times in various forums and need to do some reading there myself.

I have spent some time myself thinking on coding style and seperation of concerns. From much I have seen so far I do not actually seem to agree with the MVC model, though I seem to agree with the intent. I say **seem** because I have a sneaking suspicion the code bases I have seen using Templates are just done badly.

However, I still have a feeling I would not like MVC because it seems to place the "emphasis" if you will in the wrong place. Too often, when working in so called MVC frameworks, I find myself "wandering" the templates to troubleshoot code. This just **feels** wrong. It seems to me there should be a more directed way to quickly trace or travel to the problem code.

I realize my commentary here is somewhat fragmented and distracted. Again, I think it is simply because my experience to date has involved only bad examples of MVC and template usage. But to waffle once again, if a design concept makes it so easy to do it wrong, is there not something about the concept itself that is flawed?

Basically, I think MVC somehow revolves too much around the user experience (screens) and thus the templates become the focus for all coding. Eventually this translates to having to "walk the screens" to troubleshoot every problem. I don't think this is inherent in MVC intent, just too easy a trap to fall into. When you use a templating system that can call other templates, the result can be downright dizzying.

To summarize, I agree with you, I feel this approach is bad, I just can't properly articulate why...

Comment on Re: Code Conflation: Considered Harmful?

Replies are listed 'Best First'.

Re^2: Code Conflation: Considered Harmful?
by dragonchild (Archbishop) on Sep 14, 2004 at 00:12 UTC

Every thing that happens has one and only one place in the code that does it.
Every piece of code is broken up into functional areas. You generally have
- Formatting and layout (aka, View)
- Business-related code (aka, Model)
- Datastorage code (DBI-related stuff, generally)
- The glue code that actually runs the stuff (aka, Controller)

Your complaint about having to wander templates has to do more with how bugs are reported. Generally, the user says "Screen XYZ is doing foo when it should be doing bar". So, the debugging generally goes something like:

Look at the tepmlating for screen XYZ. Is it not displaying the right stuff?
Look at the engine routine that makes the data for screen XYZ. Is it not calling the right business objects?
Look at the various business objects called for screen XYZ. Are they doing the right thing(s)?
Look at the datastorage behind screen XYZ. Is it storing the right stuff in the right way?

So far, you're still doing the same amount of work. In fact, you might even be doing more than you would in a more naively-architected system, because you have to open more files and follow through more subroutines. And, I suspect, this is where you're stuck at.

That's because you don't see the point behind MVC. MVC adds some complexity to the architecture of a system. But, it does so in order to reduce complexity at another stage. Once you fix something in MVC, it stays fixed all across the entire application. Period.

And, there's another point behind MVC - people with different skills can collaborate on the same project. Most web applications require that everyone know language X. MVC-architected applications require that

the layout guys know HTML, CSS, and the templating language
the coding guys know language X
the datastorage guys know SQL and a little bit of language X

So, now, the coding guys don't have to know CSS. Wow, is that a relief!

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks