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.

Robert Martin has a principle of OO design called the Interface Segregation Principle: Clients should not be forced to depend on stuff that they do not use.

The PHP 5 Interface structure is one method of exposing a smaller, more limited view of oneself to different clients, one interface for each role.

Another way to accomplish interface segregation is through delegation. A class can offer a different delegate object to each of its clients, depending on the role it is performing. With both methods, the size of the interface exposed to a client object is reduced and thus the potential for dependencies.

One way to interpret this is if I have an object with 4 methods - such as read(), insert(), update() and delete() - and I have 4 presentation layer components - such as 'read a record', 'insert a record', 'update a record' and 'delete a record' - then I should create a series of delegate objects which expose to each presentation component only those methods which that particular component needs to use. This would lead to an enormous proliferation of classes within the system and would lead to a maintenace nightmare. As it offers no functional benefit it is an idea that I would avoid like the plague.

Why would people take this perverted view? Someone has taken the word 'depend' in Martin Fowler's principle and changed it to 'visible', thereby corrupting the meaning. Unfortunately this is a tendency which I have noticed time and time again in the OO world. It starts off with a perfectly valid statement, and over time various people add a bit to it, or change a word here or there, until eventually the end result is a total corruption of the original which newcomers then treat as the gospel truth! It is a bit like the game of Chinese Whispers - the message starts off as "Send reinforcements, we are going to advance", but by the time it reaches its destination it has become "Send three and fourpence, we are going to a dance".

As an example of what I am talking about take a look at Abstraction, Encapsulation, and Information Hiding by Edward V. Berard of The Object Agency who demonstrates how the definitions of 'abstraction' and 'information hiding' have come to mean different things to different people.

If different people can define different principles in so many different ways, then how on earth are us mere mortals supposed to put those principles into practice? If an individual's implementation depends upon his interpretation of those principles, then as sure as day follows night people with different interpretations will produce different implementations. Then those who used the definition containing 'visible' will accuse those who used the definition containing the word 'depend' of not obeying the rules and therefore not producing a 'proper' and therefore invalid implementation.

The major point of this particular thread is that I have created a development infrastructure which is based on a combination of the 3-tier architecture and the MVC design pattern, and I have been attacked most vociferously for producing an impure and invalid implementation because there is not a proper 'separation of concerns' between the various layers. It is the statement 'separation of concerns' which is the root of this argument. What is a 'concern'? Is it data? Is it information? Is it code? is it logic? Is it a method? Is it a property?

In my humble opion the statement 'separation of concerns' is open to far too many different interpretations and therefore far too many different implementations. Because it has far too many meanings it is virtually meaningless, therefore invalid. Software does not have 'concerns', it has 'data' (information) and 'code' (logic). A valid statement would be either 'separation of data/information' or 'separation of code/logic' as neither of these statements is open to vast amounts of (mis)interpretation.

With my own implementation I have clear 'separation of logic', not 'separation of concerns'. This means that I may have information which is defined in one component but which is not actually processed until it is passed to another component. This is (in my humble opinion) perfectly valid as it is where the information is processed which is important, not where it came from.

Here is an example of a typical criticism of my design:-

Your domain layer contains information on the structure of the database, and as this belongs in the data layer you have not demonstrated proper 'separation of concerns' therefore your design is unclean/impure/invalid/unacceptable.

My design principle was the 'separation of logic' defined by the 3-tier architecture, and as I have achieved that level of separation my design is (in my humble opinion) perfectly valid. Each object within my business layer contains information on the structure of the database table with which it is associated, and this information is passed to my data access object whenever any communication with the database is required. As I have a single DAO for my entire application and not a separate DAO for each database table the structure of individual database tables is not defined within the DAO. This means that the information must be passed to the DAO from an external source whenever any database access is required. And what exactly do I use as my external source? Why, the object that initiates the request to process some data. This means that both the data and the table structure come from the same source, which is why the table structure is defined within the class that deals with that data. I do not hold the table structure in a separate class as that (in my humble opinion) would 'break encapsulation', but that is a different argument altogether.

As is usual this objective can be achieved in many different ways, and each person has his/her preferred method. In my own implementation of the MVC design pattern the controller sucks data out of the model and then gives it to the view. The idea of passing the domain object (model) to the template (view) in its entirety sounds very fishy to me.

Yes, it's somewhat fishy because it breaks layering, but it's simple.

On second thought, it doesn't necessarily break layering, but it's easy to break layering if you do that, because it's easy to be tempted to put presentation-related methods into the domain object.

Originally Posted by Tony Marston

Surely the template would have to have knowledge of the internal structure of the domain object in order to extract the information it required?

Not normally, as far as I can tell. It typically needs only a few getter methods and doesn't need to know what these methods are attached to or how they work.

Originally Posted by Tony Marston

In my own case the process is simple because I made the decision to use XSL stylesheets as my view components. This requires the controller to suck data out of the model, convert it to an XML document which it can then give to the XLT stylesheet during the transformation process. In this way the view does not require any knowledge of the model. Indeed, an XML document is just a text file, so there is not even any knowledge of how it was created or what process created it.

This to me demonstrates a clear separation of logic. There is logic in the model which obtains data, and there is logic in the view which presents this data to the user via the user interface. The only connection between the two is the data. Although the data can change between one request and another, the logic remains the same.

As you describe it, it looks like a clear separation to me, too. I haven't studied your code, though.

I prefer to keep logic out of templates as much as I can, even view-related logic. That sometimes means I need to put the view-related logic in separate view classes.

That separation is not MVC or three-tier, it's something else. I also know you don't think there's a need for it, and I respect that.

As is usual this objective can be achieved in many different ways, and each person has his/her preferred method. In my own implementation of the MVC design pattern the controller sucks data out of the model and then gives it to the view.

Which objective? Separating presentation and domain logic? There is a misconception that any pattern that attempts this separation is MVC. I take a more precise and limited view point of MVC that is closer to the original smalltalk definition, with the controller focused on input, and translating that input into operations on the model. I've written a lot about Model View Controller.

Originally Posted by Tony Marston

The idea of passing the domain object (model) to the template (view) in its entirety sounds very fishy to me.

The idea that the controller has to sit in between the model and the view is a common misconception. There is no problem with the view accessing the model directly. Its the direction that is important. The model should not be accessing the view.

The reason for this separation is the assumption that the presentation changes more often than the domain model, and that the domain model is more general and more reusable than the presentation.

Good design manages the direction of dependencies. Unstable and specific things should always depend on more stable and more abstract things, never vise versa. Thus, the impact of change is reduced.

Originally Posted by Tony Marston

Surely the template would have to have knowledge of the internal structure of the domain object in order to extract the information it required?

The view has knowledge of the domain object's public interface. What is the problem with this?

Copying the data into the view (pushing) instead of extracting it from the model in the view (pulling) doesn't make the view any less dependent on the structure of the model. If you change the model, you still have to change the view.

I prefer to keep logic out of templates as much as I can, even view-related logic. That sometimes means I need to put the view-related logic in separate view classes.

Not having view-related logic in a template? That sounds counter-intuitive to me. While there is logic inside an XSL template it is totally unrelated to business logic. It is simply the logic required to take the XML document and produce XHTML output, and without it the XSL stylesheet would be unable to function. I have not researched other templating systems (like Smarty, for example), but I imagine they work on the principle of "you give me the data and I will produce the HTML", so there has to be logic inside the template to process the data. The very idea of attempting to remove this logic from the template does not sound workable. If you have any logic that CAN be removed then what exactly is it doing?

This is interesting. A closely related question would be: do you pass a domain object into the template and let the template suck the information it needs from it, or does layering require you to make a separate presentation-related object (or a plain array) for the template to work with?

Or, should the view use a more restrictive interface to the domain object than would be available internally to the model? This is the approach that WACT takes. The DataSource interface allows domain object accessor methods to be called from the template, but does not allow arbitrary method calls.

Not having view-related logic in a template? ... The very idea of attempting to remove this logic from the template does not sound workable. If you have any logic that CAN be removed then what exactly is it doing?

Two scenarios:

View == Template

In this scenerio, you embed view logic into the template.

View == (Helper classes + Template)

In this scenario, you put view logic into the classes and HTML into the template. It is another form of separation of concerns. Here the goal is to isolate the HTML. template view has more discussion of this concept.

One way to interpret this is if I have an object with 4 methods - such as read(), insert(), update() and delete() - and I have 4 presentation layer components - such as 'read a record', 'insert a record', 'update a record' and 'delete a record' - then I should create a series of delegate objects which expose to each presentation component only those methods which that particular component needs to use. This would lead to an enormous proliferation of classes within the system and would lead to a maintenace nightmare.

If your four operations were sufficiently complex, you might very well do that. This would be the Transaction Script pattern.

Good design is about finding the right balance. Design is navigating the tension between opposing principles. You can have classes which are too big and you can have classes which are too small. The trick is to make classes which are just right. Similarly, you can have too many objects and you can have too few objects. The trick is finding the balance.

Also, related to the earlier comment regarding Model method visibility within the View, I tend to just use a "gentlemans agreement" not to use any functions that update a model from within the view code, but if you do not trust yourself you could write a Proxy pattern that only proxies the read only methods and feed that to the View.

As I understand visibility it's metaphorically an open door whereas dependency is what happens when you actually walk into the room.

I think this is why I treat them as synonymous. I'm going to define a few terms for the purpose of this thread only...

I build a "package" of PHP code. Now anyone can access any bit of that package, but I am going to assume responsible developers here. Let's say I have written a tutorial and a few docs on how you are supposed to use the package and this is thus the "published" interface.

Now I go away on holiday for a few weeks.

Without looking at the source code, how do I know which parts of my published package have become dependencies and which parts haven't? Not just now, but in the future too. To me it feels like publishing an interface and then including it in a project is equivalent to declaring a dependency.

As is usual this objective can be achieved in many different ways, and each person has his/her preferred method. In my own implementation of the MVC design pattern the controller sucks data out of the model and then gives it to the view.

Which objective?

This was in response to the following:

Originally Posted by dagfinn

A closely related question would be: do you pass a domain object into the template and let the template suck the information it needs from it, or does layering require you to make a separate presentation-related object (or a plain array) for the template to work with? I asked that question a few months ago in this forum, and I didn't get a lot of categorical answers.

I agree with your point that the mere separation of presentation and domain logic is not automatically MVC. Taking the definition from your own artcle:

Originally Posted by http://wact.sourceforge.net/index.php/ModelViewController

Controller - receives and translates input to requests on the model or the view.

To be 'proper MVC' an application must have 3 separate components each of which performs the function of either model, view or controller. It is this level of functional separation, the separation of logic, which is vitally important. The method of communication between these components is largely irrelevant, so the description of the view which "obtains data from the model and presents it to the user" does not mean that the view MUST 'pull' data out of the model itself. It merely says "obtains", which does not close the door to the possibility that the controller may 'pull' the data out of the model then 'push' it to the view.

If you examine my own implementation of MVC you should notice that I have separate components which can be identified as performing the function of model, view and controller. My implementation may be totally unique, but that should be totally irrelevant.

Scanning down your article I see other properties of MVC which are also contained within my implementation:

The goal of MVC is to make the model independent of the view and controller which together form the user interface of the application.

An object may act as the model for more than one MVC triad at a time.

Since the model must be independent, it cannot refer to either the view or controller portions of the application. They model may not hold direct instance variables that refer to the view or the controller. It passively supplies its services and data to the other layers of the application.

Yup, all of those.

The purpose of MVC is to separate UI from domain logic. In doing so, an MVC implementation typically develops a set of reusable classes for each of the concerns in the triad.

Although not all of my components are classes, my implementation contains the following levels of reusability:

A domain object (model) can be accessed by any combination of controller and view.

I have reusable controllers, which means that a controller can be used on any model.

I have reusable views (in the form of XSL stylesheets) which means that the same view can be used on any model, and it may even be shared amongst several controllers.

The controller receives and translates input to requests on the model or view.

The controllers are typically responsible for calling methods on the model that change the state of the model. In the passive model (i.e. HTTP), the controller is responsible for telling the view when to update.

In MVC, The controller is NOT a Mediator between the view and the model. The controller does not sit in between the model and the view. Both the controller and the view have equal opportunity to access the model. The controller does not copy data values from the model to the view.

This is the only place where my implementation diverges. Due to the passive nature of HTTP my controller tells a model to do something, and when it has done it the model gives its response back to the controller. The controller then takes this response and converts it into an XML document before giving it to the view (an XSL stylesheet) for processing. Thus my views have no communication with any model.

Does the fact that my implementation breaks this one little rule mean that my entire implementation is invalid? Is this rule cast in stone, or is it open to interpretation?

Sometimes, data or behavior that firmly belongs on the user interface side of the division can conveniently be represented using the infrastructure of the model side of the division. Thus objects that would appear at first glance to be in the model are really part of the interface concern, that is the view and controller.

That is interesting as I have some information in my model which identifies for each field what kind of HTML control should be used for that field. This information is added to the XML document as field attributes and then acted upon by the XSL stylesheet. You appear to be telling me that it is acceptable whereas others have been very loud in voicing an opposite opinion. Who is right?

I think this is why I treat them as synonymous. I'm going to define a few terms for the purpose of this thread only...

I build a "package" of PHP code. Now anyone can access any bit of that package, but I am going to assume responsible developers here. Let's say I have written a tutorial and a few docs on how you are supposed to use the package and this is thus the "published" interface.

Now I go away on holiday for a few weeks.

Without looking at the source code, how do I know which parts of my published package have become dependencies and which parts haven't? Not just now, but in the future too. To me it feels like publishing an interface and then including it in a project is equivalent to declaring a dependency.

yours, Marcus

Then almost any public object is dependant on any other public object. Because technically they could access it (unless you don't include them, etc.) But then, by including them you explicitely "allow dependency". But it is not because you view something that you are dependant of it.

Let's say a class has a method, and nobody use that method. Yes, in an unlimited time aspect, you can think that it can someday become a dependancy... but if you look into refactoring your class, then you want to remove that method, what you will want to know? If anyone use it, if anyone is dependant on it. Sometime you cannot always know... but theorically I would say that if nobody use it, nobody is actually dependant of it.

To be 'proper MVC' an application must have 3 separate components each of which performs the function of either model, view or controller. It is this level of functional separation, the separation of logic, which is vitally important.

It is the separation of Domain Logic from Presentation Logic which is vitally important.

Originally Posted by Tony Marston

The method of communication between these components is largely irrelevant, so the description of the view which "obtains data from the model and presents it to the user" does not mean that the view MUST 'pull' data out of the model itself. It merely says "obtains", which does not close the door to the possibility that the controller may 'pull' the data out of the model then 'push' it to the view.

I would argue that the original concept of MVC very strongly has the idea that the View "observes" the model.

The distinction is that the model from the view perspective is not just the Domain Model, but also includes the concept of an Application Model.

Model = (Domain Model + Application Model)

This means that the division between domain and presentation does not reside exactly on the M and VC boundary:

The reason for splitting the model is that they have different rates of change and different degrees of stability. The Application model is more ephemeral, more prone to change, more closely related to the specifics of presentation implementation.

Originally Posted by Tony Marston

This is the only place where my implementation diverges. Due to the passive nature of HTTP my controller tells a model to do something, and when it has done it the model gives its response back to the controller. The controller then takes this response and converts it into an XML document before giving it to the view (an XSL stylesheet) for processing. Thus my views have no communication with any model.

I think instead, what you are doing is building an Application Model by copying values into it from your Domain Model. Your views are observing the Application Model.

I don't see the need to shield the view from the domain model. The dependency is still there, it is just more indirect. It means the controller and view are more tightly coupled by a more complex application model.

Originally Posted by Tony Marston

Does the fact that my implementation breaks this one little rule mean that my entire implementation is invalid?

did I say it was?

Originally Posted by Tony Marston

That is interesting as I have some information in my model which identifies for each field what kind of HTML control should be used for that field.

I haven't looked at your architecture, but this sounds like a Application / Presentation model, not a Domain model.

Then almost any public object is dependant on any other public object. Because technically they could access it (unless you don't include them, etc.)

I am assuming sensible people here. Declaring a dependency could just be another developer shouting across the room that their library uses my library. In the absence of that I would go by the includes (only certain top level files will be public).

Originally Posted by MickoZ

Let's say a class has a method, and nobody use that method. Yes, in an unlimited time aspect, you can think that it can someday become a dependancy... but if you look into refactoring your class, then you want to remove that method, what you will want to know? If anyone use it, if anyone is dependant on it. Sometime you cannot always know... but theorically I would say that if nobody use it, nobody is actually dependant of it.

This is why I said in practice I think they are synonymous (and I have now convinced myself). What you are describing, attempting to refactor out a method without knowing usage for sure, is the start of a potential mess. This is just the kind of problem we are trying to avoid by declaring our interfaces in the first place.

If all of the code is in-house then your test suite on your own box will pick it up pretty quick, but what if someone else has branched? What if you have published your code on the net? It means going through the tedious process of deprecating the method. That means supporting both systems for a while, publishing a new version number and an updated interface with docs. and acceptance tests. All the effort you would have to go through if there really were dependents.

I have also noticed that my UML tools and books use the words interchangeably.

The method of communication between these components is largely irrelevant, so the description of the view which "obtains data from the model and presents it to the user" does not mean that the view MUST 'pull' data out of the model itself. It merely says "obtains", which does not close the door to the possibility that the controller may 'pull' the data out of the model then 'push' it to the view.

I would argue that the original concept of MVC very strongly has the idea that the View "observes" the model.

That may have been the original idea when the concept of the MVC pattern was originally devised, but this was many years BEFORE the idea of generating output via XSL stylesheets. It is physically impossible for an XSL stylesheet to 'pull' data out of an application object - this has to be converted into an XML document so that it can be 'pushed' into an XSL transformation process.

You seem to be saying that the rules of MVC require that the view 'pulls' data from the model whereas the use of XSL stylesheets requires that the data be 'pushed' via an XML document. Does this mean that it is impossible to use XSL stylesheets in the MVC design pattern?

Originally Posted by Selkirk

Originally Posted by Tony Marston

Does the fact that my implementation breaks this one little rule mean that my entire implementation is invalid?

When you say 3-tier, i think three different machines, or at least 3 different processes or 3 different platforms, such as:

Web Server

Application Server

Database Server

This is a common misconception. However there are actually two types of 3-tier architecture, a 'logical' and a 'physical', as discussed in http://www.marston-home.demon.co.uk/...rhardsoft.html. It is possible to have 'logical' 3-tier without 'physical' 3-tier, but before you can deploy your application over different separate bits of physical hardware you must first perform the logical separation so that you actually have different components which run on the different pieces of hardware.

I haven't looked at your architecture, but this sounds like a Application / Presentation model, not a Domain model.

My system is based on the 3-tier architecture which has a presentation, business, and data access tier. The 'model' part of MVC equates to the business tier.

The term 'application model' has a totally different meaning to me as my previous language used a component called an application model which was in fact a data dictionary. It was possible to have two versions of the application model - one for use by the business layer (the BAM) and one for use ny the presentation layer (the PAM). This is where the same terminology with different meanings causes confusion.

It is physically impossible for an XSL stylesheet to 'pull' data out of an application object - this has to be converted into an XML document so that it can be 'pushed' into an XSL transformation process.

That is, unless you use XSLT extensions and access your application components directly from your stylesheet.