The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I'm also trying to create a template based solution. At the moment my "flow" sort of looks like this: FrontController -> "Command" -> View -> Template

It feels like one of them is redundant. Should I really have to create three files (command, view, template) for each "new" page? I'm curious how you solved this. Is it possible to integrate the "Commands" into the FrontController or something?

FrontController and Commands(which are also called Controllers in MVC parlance) are different concepts. I would not try integrating them.

Most of my pages do end up with three classes, each in their own file. But keep in mind that you may end up with a controller driving multiple views or possibly multiple controllers using the same views. Views themselves often end up being composites which means they get broken up into smaller classes which in turn will get shared between multiple views. And some controllers will not have any views, they just redirect.

The model is another name for the domain layer not the data access layer.

I've always considered both the domain- and data layers to be part of the model. Where the domain layer handles the 'logic' and the data layer handles the IO (database, file or other). However, an ActiveRecord type of solution combines both layers while a more classic approach separates the two.

If you announce that you're going to have a separate view and controller - MVC - and then don't bother to keep them apart you might as well claim to be a vegetarian and then insist that vegetarians are free to implement vegetarianism with as many degrees of meat-eating as they like.

Again, you're coming up with silly analogies that make no sense. Vegetarianism is defined as a strict, 100% no meat lifestyle. MVC is a design pattern that was never classed a a strict 100% no mixing of view and controller. No design pattern is defined in a strict must-follow recipe. The degree of separation depends entirely on the context.

The model is another name for the domain layer not the data access layer.

McGruff, is your sole purpose in life to argue and make nonsensical comments? The model layer is where all the data access happens (communication with databases, flat file storage, etc.), so YES it IS the data access layer.

Martin Fowler's eaaCatalog has two separate categories called "Domain Logic Patterns" and "Data Source Architectural Patterns". Guess which one has ActiveRecord, TableDataGateway, RowDataGateway, and Data Mapper - the patterns typically found in the MVC "Model" layer?

The catalog even describes the ActiveRecord pattern as "An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data."

Encapsulating database access is the primary function - data access. Don't make arguments where there is no purpose. You knew as well as everyone else does what I mean when I say the "data access" layer.

Lastcraft put it best with (and I paraphrase) - "the model in MVC is everything else that the controllers and views aren't".

So it's the data access layer and the domain layer. Though I guess you could argue that in a well designed application the controllers and view should only interact with the domain layer. Again, the level of layer interaction strictness is dependent on the problem.

McGruff, is your sole purpose in life to argue and make nonsensical comments?

Usually my purpose is to steer clear of MVC topics. It causes endless confusion but it's impossible to do anything about that. It's the tenth circle of hell.

TableDataGateway, RowDataGateway, and Data Mapper are data access patterns. They just fetch and carry raw data but don't have any domain logic.

ActiveRecord isn't the same thing at all: this is a domain object. Although it does also know how to persist its data the interesting bit is the domain logic. Fetching and carrying isn't interesting; nothing is really happening - just data shuffling backwards and forwards across an application boundary. This and domain logic are two very different things. It doesn't help that people often describe RowDataGateways as ActiveRecords.

I suppose you could think of the model as encompassing domain and data access but I think that's a bit confusing. Domain layer and data access layer are better terms and you'll virtually always find this distinction being made in a well-designed app. I'd never talk about models at all unless someone else raised the term.

Really what MVC is all about is introducing the idea of presentation, domain and data access to programmers taking their first steps in OOP. MVC is the buzz word that everyone latches onto but you can't understand MVC without first understanding presentation, domain and data access. I'd leave the view controller split until later because it's a little harder to understand the significance of that. Hardly anyone ever gets it in any of the articles you can find.

I have read about the difference between the Page Controller and Front Controller patterns. These were especially helpful:
- Page Controller
- Front Controller

I've decided to wait with the Front Controller and focus on the Page Controller pattern for now, since it's one less layer of complexity. What I'm wondering is, do you implement your Page Controllers as classes based on a BaseController (like the Microsoft examples) or as procedural code? The advantage of having a BaseController is obviously that you can put some common stuff there.

But if a Page Controller is a Class, and at the same time the entry point of the application, where do you instantiate it? After the class declaration?

Hi pakmannen,
Yes, you need to declare the controller class then instantiate it. And of course if you are leaning towards an OOP approach then minimizing code outside of classes is a good thing.

I read your links and they do provide a good summary. I'm not entirely sure that I agree with the notion that a Front Controller is significantly more complicated than a Page Controller. But to each their own.

Thanks for the reply ahundiak. I wouldn't say Front Controllers are significantly more complicated, but they do seem redundant in many cases. Correct me if I'm wrong, but a Front Controller merely forwards to a Command, which is practically the same thing as a Page Controller. In many cases it feels like the Front Controller is doing what the Web server itself should do: serve pages. I'm sure the Front Controller is good for complex websites, but if you don't have a need for it, Page Controllers seem more sensible. But what do I know eh?

We have to have clearly defined ideas so that we can communicate and so that we can analyse common problems effectively.

The reason to separate views and controllers is to isolate change. MVC allows you to change the view without also changing a controller. There aren't really any shades of grey: you either have to change controller code when you change a view or you don't. That prohibits controllers passing data - variables or "model" objects - to views since clearly you'll have to change the controller when the data displayed in a view changes.

That's not to say this is bad design. In a sense it's not design at all: the controller happens to have some domain objects lying around so they get chucked at the view simply because it's convenient rather than through any conscious choice. Still, if your controllers and views don't need to vary independently it doesn't doesn't matter if they are merged in a single presentation layer (just don't call that MVC).

If we use a refactoring app as an example, the domain action is to hunt through a filesystem, editing files. A controller will send messages to various domain objects to achieve this, but what about a view? There are all kinds of possibilities, eg:

(1) one-liner: "operation succeeded/failed"
(2) list every file which was edited
(3) print diffs for every file which was edited
(4) display the results of an "all tests" run using an app like SimpleTest

In each case the domain action is exactly the same. If data were passed in to the view from a controller the controller has to be changed when the view details change. Separating controller and view would be useful if you want to support several view types. Maybe you're exploring a new domain and can't decide yet.

The value of a front controller lies in the fact that it isolates your commands from the actual web server. You can make yourself a nice HTTPRequest and HTTPResponse objects, let the front controller init them and then your commands need never worry about $_GET or $_POST again. Especially nice if you buy into the notion of unit testing.

The other thing with using a front controller is that you only need one simple php file in the actual web directory. Correct me if I am wrong but with the basic Page Controller implementation, each page controller file need to be in the public web directory. To me at least this seems to make deployment and maintenance more difficult.

So I guess I would argue that even for a simple website, a front controller is easier. It doesn't have to be fancy. You could use an url like:

I'd keep classes in separate files from runner code. You'll get in a mess if you don't. Also, this allows you to store a code library outside of the web root which is better from a security point of view.

A FrontController provides a common way of processing requests. Inheriting from a shared PageController class does much the same thing.

I'd keep classes in separate files from runner code. You'll get in a mess if you don't. Also, this allows you to store a code library outside of the web root which is better from a security point of view.

How would you do that with a Page Controller pattern? (IE, no Front Controller) I do not see how you could make your PageControllers classes AND entry points without instantiating them after you declare them. Could you provide a quick example perhaps?

That prohibits controllers passing data - variables or "model" objects - to views since clearly you'll have to change the controller when the data displayed in a view changes.

What about GET information such as $id, $page, $limit etc? A View would need this information when it calls the Model to get the things it wants. Wouldn't the controller need to pass this on to the View? Or should the View access this directly from the $_GET?

Still, if your controllers and views don't need to vary independently it doesn't doesn't matter if they are merged in a single presentation layer (just don't call that MVC).

I read somewhere that this is called the Document-View pattern, where Document is the data and View is input/output. I guess you need to separate the View and Controller if you want more than one Controller to serve the same View (and avoid code duplication). AddItemController and RemoveItemController both serve the ListItemsView for instance. If you would combine the Controller and View (in a Document-View pattern) you would have the same code (Fetching the Model state) in both files.

In the simple example above, that may not seem like a problem, but what about when you have hundreds of Page Controllers? You end up with a massive switch statement or perhaps something disguised in an array, an XML document or whatever. For every page request, PHP will have to reload a bunch of data which is irrelevant to the current request the user is trying to perform.

This is simply a strawman argument. Of course you don't want a huge config file or massive switch statement. Which is why people doing big sites break things up into modules. And if you look at the example I gave in which the command class name is derived from a request argument then the need for even a switch statement goes away. In any event, notice that the author is arguing that for simple sites front controller works well, it's only when you develop complex sites that difficulties might ensue. Just the opposite of what you were offering as the reason for choosing Page Controller over Front controller.

The article then goes on to saying:

The other problem with running everything through a single PHP script, such as index.php, is it imposes a significant restriction on the flexibility PHP offers, by default, of allowing developers to “drop a script” anywhere under the web server’s web root directory. Adopting this approach will likely cause you problems later, both from the practical perspective of having to updating the command hierarchy each time you create a new file to issues like integration with other PHP applicatoins.

For lack of a better word, this is just plain nonsense. Even with a front controller you can still drop scripts pretty much anywhere you want. And if you are trying to integrate another application (which, IMHO, falls under the header of complexity) what would rather have? One file to mess around with or several hundred files that need to be moved to the web root directory?

The article also has:

But the word serve should set off alarm bells. PHP is not a web server itself (ignoring the odd exception) but used as an add-on to an existing web server, such as Apache. It’s Apache that does the serving, not PHP.

Which again is a bit of a stretch. It is up to PHP to decide how to process a given request. Deciding which command to use for a given request is a trivial part of the entire process.

What seems a bit funny is that as you read through the result of the article, the author almost seems to convince himself that maybe front controllers are not such a bad idea after all.

What about GET information such as $id, $page, $limit etc? A View would need this information when it calls the Model to get the things it wants. Wouldn't the controller need to pass this on to the View? Or should the View access this directly from the $_GET?

The kind of separation I've been talking about requires another part of the system: an assembly layer. Some kind of dumb assembler object would wire everything up together. It's "dumb" because that's about all it does; there's very little logic in here. You might receive input in some kind of request object then controller and view both get a reference to it. Same with domain objects (or "models", if you like) with the proviso that the view is always read-only. Only the controller is allowed to manipulate domain objects.

We have to have clearly defined ideas so that we can communicate and so that we can analyse common problems effectively.

We do have clearly defined ideas. I have no problem understanding the more strict solution you have defined nor do I have a problem understanding the more blurred approach others have defined. I have successfully used both methods depending on how complex the application is. This is basic stuff - I don't see how you can get quite so worked up about it.

You can make yourself a nice HTTPRequest and HTTPResponse objects, let the front controller init them and then your commands need never worry about $_GET or $_POST again. Especially nice if you buy into the notion of unit testing.

This sounds interesting, where can I read about that? Tried to google and search sitepoint but no luck.

The your front controller just does:

PHP Code:

$command = new $controller($request,$response);$command->$action();

I've wondered about this. The "action" is a method of the command correct? What kind of method would that be? I thought you'd mostly have an Execute() method which you call manually where everything takes place.

I'm really not seeing where the redundancy is coming in.

Do you not agree that Commands and PageControllers are extremely similar? A FrontController seems to be something that binds PageControllers together, and so far, without talking about filters or request objects, which I know nothing about, I don't see the point. I'm sure I will eventually.

When using a Front Controller, do you really need a Command for every View? Could you not do something like this:

index.php?view=myview
index.php?command=mycommand

For static pages, where the Model is never updated (and hence, a Command would do nothing but choose a View) could you not leave the View selection up to the Front Controller? And when you DO need to update the Model, the Front Controller invokes a Command which selects the View.

Do you not agree that Commands and PageControllers are extremely similar? A FrontController seems to be something that binds PageControllers together, and so far, without talking about filters or request objects, which I know nothing about, I don't see the point. I'm sure I will eventually.

Almost: Page/FrontController are input controllers ie they receive input, decide what to do about it, then pull levers and press buttons to make it happen. A FrontController might hand over to something quite similar to a PageController except that it doesn't receive input.

Originally Posted by pakmannen

You wouldn't want to have 50 controllers tucked in a folder and then 50 files like that calling them. Then you'd automate the process into one file and voila: a FrontController. Right?

If you like. Either is OK.

Originally Posted by pakmannen

Back to Controller/View separation. If you're using a Template as well, does this look alright:

A factory object can take over object instantiation, injecting all the dependencies. This is what I'd call a dumb assembler with little or no logic of its own apart from how to wire everything up. For example, in the above code the controller decides which view it wants and then asks the assembler for it.

This is a powerful technique which leads to very flexible designs. Since the classes now depend on an interface rather than a specific class, you can easily change the behaviour of the system simply by passing different objects in.

This also helps make make code easier to (unit) test. In a test, mock objects can be passed in.

With OOP, we spend all our time fencing code off into discrete components but this creates a problem: how do we get everything talking to each other? Anything in the assembler scope can be introduced to anything else so most of your how-to-get-from-A-to-B-problems just disappeared.