Data Access Layer - Is there a real seperation?

[DougBTX]

Brenden Vickery
Putting "class Default_Table {" before a list of procedural functions and "}" after the list does not make the code Object Oriented.

I beg to differ.

If the distinction between code that simply has classes and code that is object orientated is arbitrary to you, then you might want to take a second look at it.

If you put pure procedural code into an object, it is still procedural code. It can't be orientated around objects if it is just procedural code modularized using classes.

it is far better to have something which breaks some arbitrary set of rules but which works than it is to have something which obeys those rules but which fails to work.

Lines like this serve only to irritate, they don't say anything constructive or interesting.

Code that works in better than code that doesn't work. This is as true for all code, procedural and OO.

You may implement the 3-tier architecture in a different way, but as long as it fulfills its purpose it would be a perfectly valid implementation, just as mine is a perfectly valid implemenation.

But an implemenation of what? Just because it "works" does not mean that it is an implemenation of a 3-tier architecture.

My motto is "innovate, don't immitate", so I will always look for a different way, a better way.

Then live by it, don't just say so. When using other people's words to describe your code, and it appears that your code is not described by those words, expect people to tell you that your code is "wrong".

For example, putting procedural code in a class and saying that it is suddenly not procedural will get negative comments.

Douglas

[DougBTX]

The definition of encapsulation is quite clear - all the properties and methods for an object must go into a single class.

It is even simpler than that. Here is one definition:

Methods surround and hide the object's nucleus ["the object's variables" fig. 1] from other objects in the program. Packaging an object's variables within the protective custody of its methods is called encapsulation.

fig. 1:



And a list of other ones: http://www.google.com/search?q=define%3Aencapsulation

Note that the definition above does not mention how objects should be defined, nor how many objects there should be, nor how much code should go in an object's implementation.

It is simply a statement that objects have data and methods.

Encapsulation, along with the other three "principles of OOP" are language level principles. They say nothing about the overal design of a OO system, so you cannot use them to back up your design choices. As one of the articles you linked to earlier states, "encapsulation doesn't even ensure basic object-oriented objects." If it can't ensure OO objects, you obviously can't use it to demonstrate that your objects are OO.

Douglas

[MickoZ]

Doug: Well Tony maybe talked a lot about OO, but he somehow admitted it was not OO code 100% as in OO Design ;-)

I think however it will be nice to know what other people trying to do the same as him if it is really more productive or what. If it is really faster than how he claims it, etc.

[lastcraft]

Hi...

I want something very flexible and if possible the most simple as possible. Note: there is some complex logic/structure in the apps.

You definitely want to go for a domain model system. Start with ActiveRecord and factor it out later once you know what system you want. There are several libraries that you may want to look at: Propel, PEAR:: DB_DataObject, MetaStorage or whatever. At the early stages you won't know for sure which one though or whether to roll your own. ActiveRecord is the simplest approach so go with that first.

yours, Marcus

[MickoZ]

lastcraft:
is Active record like:

Class Something
{
  function save()
  {
    if ($this->id is null)
    {
      // insert
    }
    else
    {
      // update
    }
  }
  
  function load($id)
  {
  }
}

I already began do that in the last code I dev'ed for my prototype if that is it... it is not bad, but when beginning to deal with a lot of collection, etc. I guess I might want to try that lazyload stuff (I guess that lazyload pattern is load it when you need, I thought to do stuff like that.) I have typed some draft code (for idea on how to do different thing) yesterday and I will probably show it if I need to get a proof of concept.

Is the book from Fowled explain the pattern clearly, etc. (I guess so) and is there any "good tutorial" on the same pattern over the net. I guess I should buy the book and read it slowly, it mights show what I thought and what is the "best way" to do the thing I though (see think about the thing I have not anticipated I guess)

[lastcraft]

Hi...

Do you also agree with the person who says that Inheritance breaks Encapsulation?

This article is a bit C++ish. That issue has been pretty much resolved with interfaces. In fact C++ users have been simulating Java interfaces for some time. You certainly don't have to add any friend modifiers to algorithm extensions in the STL for example (a classic illustration of the Strategy pattern).

That is simply your opinion which I do not share. My infrastructure conforms to the principles of the 3-tier architecture, so my business objects have all the properties and methods they need to act as intermediaries between the presentation and data access layers. You may implement the 3-tier architecture in a different way, but as long as it fulfills its purpose it would be a perfectly valid implementation, just as mine is a perfectly valid implemenation.

3 tier is not about dividing up code. You could do that just by placing different source files into different folders on your hard drive and claim it was "3 tier". 3 tier is about severely restricting visibility across those boundaries. If you fail to do that then you don't have a 3 tier architecture. There is no room for opinion here, you simply don't understand the definition if you've not done this.

Similarly my presentation layer, which is responsible for building all the HTML screens, *must* have some knowledge of what fields need to be displayed, in what order, with what labels and with what controls.

It only needs a method call, not a label. You don't add features to anapplication starting from the database end in any case. You start from the application and add whatever relations are needed to support it. The point of tiering is that they need to be in no way connected. 3-tier means that they have no forced connection with the view either. It woud be a very trivial app. indeed that simply displayed every field exactly as i appeared the in the DB.

Therefore it is the choice of transaction which governs which JOIN statment to use. As the transaction is a presentation layer component the request for a particular JOIN must come from the presentation layer, pass through the business layer, and be executed by the data access layer. I could get the presentation layer to say "give me join number 21", but I'm even less ahppy with that idea. How would you handle this in your infrastructure?

By having a point of indirection between the low level DB transaction and the business level transaction. The higher one is usually called the UnitOfWork and exists in the application. This one handles the DB or other forms of transaction, although it's common for them just to chain through. If you are dealing with long transactions (a bad idea in a web app.) then you should make the UnitOfWork serialiseable and treat it as part of the session. That way it stays in the application layer, which means that the presentation layer can see it. The presentation layer should handle sessions.

I beg to differ. If I write code that uses the OO functions within PHP, and that code follows the basic principles of OOP and exhibits the properties of encapsulation, inheritance and polymorhism, then by its very nature that code is OO.

Nope.

That may not be the proper way according to your rules, but it works!

I could write the whole app. in 8086 assembly language and it could still work. It would hardly be a legacy I would like to leave behind.

yours, Marcus

[lastcraft]

Hi...

So you agree that adding a field to a view requires changing the business object to recognise and deal with that new field. And by definition you must add it the database otherwise its value will be lost.

You really don't understand do you ? I've answered this about three times now. Please reread the earlier comments by myself and others.

So you are allowed to take shortcuts then? I take shortcuts to keep things simple and easy to maintain.

From what I have seen so far your choice of shortcuts does the exact opposite. Having table names rippling upward will cause a maintanence headache.

The shortcuts I am describing are in restricting the OOness of the domain objects in favour of less infrastructure code. An isomorphic mapping is the lowest common denominator (it seems you don't quite have even this). PEAR DB_DataObject is of this type. Adding one to many relationships, etc, as with Propel is the usual compromise. Java has the JDO spec (and Hibernate) which support various forms of aggregation and inheritance and have object query langauges on top. That would be a very complete separation, but one we can only currently achieve in PHP with hand coded mappers.

yours, Marcus

[lastcraft]

Hi...

So what? The email address has to be visible somewhere otherwise how else can it be input and maintained?

Just because it is input in one particular screen, does not mean it has to be visible to every other part of the application. In fact if you have one screen (do people really still think in "screens" these days ) that enters emails and another that enters it as an instant messenger service, how will your system cope. You have exposed the implementation by which you send messages. You have broken encapsulation yet again.

Several times you have claimed that you open to new ideas. I have just presented an alternate scheme that is superior on just about every senario and you still don't listen. Amazing.

With my approach all the User class does is satisfy a request for data, and what happens to it after that is a matter for the controller which may pass it to a view of its choosing.

It means that your application is actually distributed amongst the various controllers. It means that your M and C in MVC have started to become hopelessly mixed up. The M in MVC stands for "model". If they meant "database" they would have called it DVC.

Let me enlighten you: The 3-tier architecture has its application logic split across the following tiers (aka layers):

• Presentation logic = User Interface, displaying data to the user, accepting input from the user.
• Business logic = Applying business rules, ensuring the data is valid before being pased to the database.
• Data Access Logic = Database Communication via the relevant API's.

Having a separate data access layer means that you can switch from one DBMS engine to another without changing any logic in the other layers.

You have managed to enlighten me, but mainly in the extremes of human nature. Separation is not the only requirement, but also limiting the visibility to the next lower layer. You've broken that and it has been painstakingly explained to you at least four times now. The degree of breakage is not that great, it's a fair go for a first attempt, but that breakage is still there. I suspect that you could probably clean up it pretty easily. If you tried.

The 3-tier architecture was promoted in the language I used prior to PHP as it made it possible to have an application with a client-server interface and to enable it for the web simply by adding on a new HTML interface which could share all the existing business and data access logic.

If they had near identical navigation and screens, then you did not change the presentation layer, all you did was port details of the front end. I don't know the exact nature of your "port", so I'll reserve judgement. Given some of the claims you have made so far I am not convinced that a change in the design of the interface would not dictate major changes in the rest of your software. Being able to port once does not make it 3 tier (should be 4 tier these days by the way). Being able to port it every time makes it 3 tier.

If a graphic designer's skills are limited to Dreamweaver and exclude the hand-coding of XHTML, CSS, XML and XSL then he is not much use in my book.

Designers are an essential business asset that have a core role in e-commerce projects. They are judged on their graphic design, usability and marketing skills and good ones are hard enough to find anyway. For the business stakeholders to be told by the technical staff that they must limit their designers to ones proficient in XSLT would be arrogant beyond belief. You wouldn't be arrogant would you?

yours, Marcus

[lastcraft]

Hi...

There are many ways to choose from, each with their own sets of advantages and disadvantages, and provided that the chosen method works and both the developers and the end users can live with the advantages and disadvantages, then all in the garden is rosy.

When combinations don't work well together then they just create extra work or problems. Your garden seems to have more than a few weeds. It might be time to break out the DDT.

Except, it appears, when it's MY garden when I am vilified for daring to be different.

You haven't been vilified for your project at all. You have been rightly vilified for inflated claims and an insecure attitude. I don't see that changing anytime soon.

My motto is "innovate, don't immitate", so I will always look for a different way, a better way. If some people regard me as a heretic for daring to question their view of the universe, then so be it.

This is all rather sad.

Because you have never looked beyond your favourite two pattern books (whatever they are) everything looks innovative to you. There is nothing innovative in your system except where you have committed some kind of random design error. The data gateway patterns are the most primitive of all, but somehow you still managed to mix them into a confusing mess. You have used a TransformView over a TemplateView in the one and only set up where it's complete overkill. TransformView is way more infrastructure than templating and poses restrictions on the skills of the developers and designers. Hardly KISS.

This is not heretical any more than any beginner's mistakes are heretical. Getting beyond this requires nothing more than letting people point you in the right direction. You don't even have to listen to what we suggest and I wouldn't want anyone to take my word as gospel. It does require you to take the trouble to read at least the Fowler books, however. Then you can go and make up your own mind.

Ignorance certainly isn't bliss for the people who have to put up with it.

yours, Marcus

[Tony Marston]

If the distinction between code that simply has classes and code that is object orientated is arbitrary to you, then you might want to take a second look at it.

If you put pure procedural code into an object, it is still procedural code. It can't be orientated around objects if it is just procedural code modularized using classes.

OOP is nothing more than creating classes which have methods and properties. By creating a different class for each object you demonstrate encapsulation. By sharing common code through subclassing you demonstrate inheritance. By having common method names on different classes you demonstrate polymorphism. My code contains all those features, therefore it is OO. It may not be your flavour of OO, but it is OO all the same.

If not there are plenty of OO tutorials on the web which are also wrong. I have seen several which show how to take some procedural code and do it 'the OO way', and guess what? The code looks more or less the same, but simply enclosed in "class whatever{}".

it is far better to have something which breaks some arbitrary set of rules but which works than it is to have something which obeys those rules but which fails to work.

Lines like this serve only to irritate, they don't say anything constructive or interesting.

They irritate you because I choose not to follow your arbitrary set of rules yet stll manage to create code which works, and which works rather effectively. With the exception of MickoZ nobody has made any constructive comments on my code. Every one else wants me to change my code so that it operates according to their rules, and as I see no benefit in these rules I regard them as destructive and choose to ignore them.

[dagfinn]

So you agree that adding a field to a view requires changing the business object to recognise and deal with that new field. And by definition you must add it the database otherwise its value will be lost.

Then why do you and others keep telling me that if I cannot change my database schema without changing my business and presentation layers then I don't have tiering?

If I add a field to the database then I must change the view otherwise it wont't be displayed. I must also change the business layer otherwise it won't be validated.

FYI adding a new field to a view in my infrastructure does not require adding a new method to a business object.


So you are allowed to take shortcuts then? I take shortcuts to keep things simple and easy to maintain. That is why I do not waste my time with unnecessary bloat.


If you add a new field to a screen, but do not store the user's data in a corresponding new field in the database, then how is the user expected to retrieve the data that he keyed in?

I don't intend to get into the details of this discussion; there's just too much to sort out. I just offer this quote from Martin Fowler that seems relevant to what you're saying:

Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.

[dagfinn]

This article is a bit C++ish. That issue has been pretty much resolved with interfaces. In fact C++ users have been simulating Java interfaces for some time.

Hmmm...
Why extends is evil may be more relevant.

An interface is the same thing as an abstract class with no implementation, except for the fact that you can do multiple inheritance with them. Thinking about them in a single inheritance context is the most interesting aspect.

3 tier is about severely restricting visibility across those boundaries. If you fail to do that then you don't have a 3 tier architecture. There is no room for opinion here, you simply don't understand the definition if you've not done this.

I believe you mean dependency rather than visibility. And especially restricting upward dependencies. Otherwise, I would have to disagree with you.

[Tony Marston]

You may implement the 3-tier architecture in a different way, but as long as it fulfills its purpose it would be a perfectly valid implementation, just as mine is a perfectly valid implemenation.

But an implemenation of what? Just because it "works" does not mean that it is an implemenation of a 3-tier architecture.

My infrastructure conforms to the principles of the 3-tier architecture, so my business objects have all the properties and methods they need to act as intermediaries between the presentation and data access layers. You may implement the 3-tier architecture in a different way, but as long as it fulfills its purpose it would be a perfectly valid implementation, just as mine is a perfectly valid implemenation.

3 tier is not about dividing up code. You could do that just by placing different source files into different folders on your hard drive and claim it was "3 tier". 3 tier is about severely restricting visibility across those boundaries. If you fail to do that then you don't have a 3 tier architecture. There is no room for opinion here, you simply don't understand the definition if you've not done this.

The definition of the 3-tier architecture is very simple - you take your application logic and split it into 3 separate tiers or layers. All user interface (UI) logic goes into the presentation layer, all business logic goes into the middle business layer, and all data access logic should go into the data access layer. The only 'rule' is that no component in the presentation layer must talk directly with the data access layer, it must all go through the business layer.

There are two major objectives to this architecture:

• In order to switch from one database engine to another you simply change the component in the data access layer. This should not need any changes in any of the other layers.
• Should you wish to change the user interface, such as from client-server to the web, you simply need to change the components in the presentation layer. You may instead create new ones so that you can have the client-server interface and the web interface running at the same time. This should not need any changes in any of the other layers.

In other words all the code you write for the business layer (which is where the bulk of the code goes) is independent of the other two layers and does not need to be changed should either the DBMS engine or the UI be changed. This therefore protects the investment made in constructing a separate business layer.

There are no other rules. There are no implementation details, there are no rules governing what information needs to be passed between the different layers, or how they should be passed. There is just a simple list of objectives. If you write code which meets those objectives (as I have, in two different languages) then what you have is 3-tier. The fact that my implemenation is different from yours is totally irrelevant.

If you have found authors who have created additional rules for the 3-tier architecture, and you choose to follow those rules, then that is your choice. Personally I do not recognise any additional rules, so I do not waste my time implementing them. That is my choice.

[dagfinn]

The definition of the 3-tier architecture is very simple - you take your application logic and split it into 3 separate tiers or layers. All user interface (UI) logic goes into the presentation layer, all business logic goes into the middle business layer, and all data access logic should go into the data access layer. The only 'rule' is that no component in the presentation layer must talk directly with the data access layer, it must all go through the business layer.

This doesn't look too unreasonable to me. But you're right that there are differing rules. Fowler has this:

Together with the separation, there's also a steady rule about dependencies: The domain and data source should never be dependent on the presentation. That is, there should be no subroutine call from the doamin or data source code into the presentation code...The relationship between the domain and the data source is more complex and depends upon the architectural patterns used for the data source.

[Tony Marston]

Note that the definition (of encapsulation) does not mention how objects should be defined, nor how many objects there should be, nor how much code should go in an object's implementation.

It is simply a statement that objects have data and methods.

Encapsulation, along with the other three "principles of OOP" are language level principles. They say nothing about the overal design of a OO system, so you cannot use them to back up your design choices. As one of the articles you linked to earlier states, "encapsulation doesn't even ensure basic object-oriented objects." If it can't ensure OO objects, you obviously can't use it to demonstrate that your objects are OO.

The article actually contains a fuller description:

Encapsulation is a language construct that facilitates the bundling of data with the methods operating on that data. Information hiding is a design principle that strives to shield client classes from the internal workings of a class. Encapsulation facilitates, but does not guarantee, information hiding. Smearing the two into one concept prevents a clear understanding of either.

The Java language manifestation of encapsulation doesn't even ensure basic object-oriented objects. The argument is not necessarily that it should, just that it doesn't. Java developers can blithely create bags of data in one class and place utility functions operating on that data in a separate class. So as a first rule:

Encapsulation rule 1: Place data and the operations that perform on that data in the same class.

This standard practice creates classes that adhere to the principles of abstract data types.

How does that differ from the definition of encapsulation which I have previously quoted?

[Tony Marston]

Similarly my presentation layer, which is responsible for building all the HTML screens, *must* have some knowledge of what fields need to be displayed, in what order, with what labels and with what controls.

It only needs a method call, not a label. You don't add features to an application starting from the database end in any case. You start from the application and add whatever relations are needed to support it. The point of tiering is that they need to be in no way connected. 3-tier means that they have no forced connection with the view either.

Your original criticism of my infrastructure was that it was not possible to change the structure of the database without making changes in all 3 layers. Changing the structure of a database may involve adding (or removing) fields from a table, and in order to do so you need to change the business layer to add (or remove) details on how that field is to be validated. You also need to change the presentation layer to add (or remove) that field from the screen definition.

So you agree that adding a field to a view requires changing the business object to recognise and deal with that new field. And by definition you must add it the database otherwise its value will be lost.

You really don't understand do you. I've answered this about three times now.

No you haven't. You claim that it should possible to change the structure of a database without having to make corresponding changes in either the model or the view. I have asked you 3 times to back up this claim with details, and so far you have failed to provide those details.

I must thank dagfinn for providing this valuable quote:

Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.

So if Martin Fowler, your 'god', says that it must be so, then who are you to argue?

It woud be a very trivial app. indeed that simply displayed every field exactly as i appeared the in the DB.

I agree. However, my infrastructure does not do that, so what makes you think that it does?

[Tony Marston]

Several times you have claimed that you open to new ideas. I have just presented an alternate scheme that is superior on just about every senario and you still don't listen. Amazing.

True, you have presented alternative scenarios, but as to them being superior? That is a matter of opinion.

[Tony Marston]

The definition of the 3-tier architecture is very simple - you take your application logic and split it into 3 separate tiers or layers. All user interface (UI) logic goes into the presentation layer, all business logic goes into the middle business layer, and all data access logic should go into the data access layer. The only 'rule' is that no component in the presentation layer must talk directly with the data access layer, it must all go through the business layer.

This doesn't look too unreasonable to me. But you're right that there are differing rules. Fowler has this:

Together with the separation, there's also a steady rule about dependencies: The domain and data source should never be dependent on the presentation. That is, there should be no subroutine call from the doamin or data source code into the presentation code...The relationship between the domain and the data source is more complex and depends upon the architectural patterns used for the data source.

When I say that no component in the presentation layer must talk directly with the data access layer I also imply the opposite, that the data access layer should not make calls directly on any component within the presentation layer. In fact, the data access layer should not even make calls into the business layer, it should only give responses to requests. Similarly with the business and presentation layers.

That is exactly how my infrastructure works.

[DougBTX]

How does that differ from the definition of encapsulation which I have previously quoted?

That definition does not explain why you should put everything related to a user in a single class. It is like saying that all the code in the application should go an an Application class. Why is this not good? Because,

you want more of your objects; you want them to represent cohesive, workable entities. A second rule concerns the manner of choosing the data and operations to encapsulate:

Encapsulation rule 2: Use responsibility-driven design to determine the grouping of data and operations into classes

There are lots of responsibilities which need to be looked at to manage a user. Adding a user and sending an email to a user are different responsibilities, which should therefore be encapsulated in different classes to get object orientation.

Douglas

[Tony Marston]

With my approach all the User class does is satisfy a request for data, and what happens to it after that is a matter for the controller which may pass it to a view of its choosing.

It means that your application is actually distributed amongst the various controllers.

Yes, many. Each user transaction uses a specific controller which supervises all communication with the other components in the application in order to carry out the task required by the user. Regardless of which controller is used, all the model has to do is satisfy a request for data. Once the model has supplied the data to the controller the model is no longer in the loop, and it is up to the controller to deal with the data as it sees fit. This may mean writing it out to an HTML document, a PDF document, a SOAP document, an email message or whatever. How the data is dealt with is not the responsibility of the model, but of the controller with its various view objects.

It means that your M and C in MVC have started to become hopelessly mixed up. The M in MVC stands for "model". If they meant "database" they would have called it DVC.

The mix up is entirely in your mind. The 'model' in MVC is exactly the same as the business layer within the 3-tier architecture. The 'view' and 'controller' both exist in the presentation layer.

Having a separate data access layer means that you can switch from one DBMS engine to another without changing any logic in the other layers.

You have managed to enlighten me, but mainly in the extremes of human nature. Separation is not the only requirement, but also limiting the visibility to the next lower layer. You've broken that and it has been painstakingly explained to you at least four times now.

Excuse me, but separation of logic is the only 'requirement' in the 3-tier architecture. 'Limiting of visibility' sounds like a bolt-on rule to me, and one that can be difficult to explain, let alone enforce. Information may exist in or be visible to any layer, but it is where that information is processed which is important. Data retrieved from the database starts off in the data access layer, goes through the business layer and into the presentation layer before it is displayed to the user. Conversely, data input by the user is received by the presentation layer, given to the business layer which in turn gives it to the data access layer so that it can be written to the database. This data has to pass through all three layers, so how can you 'limit its visiblity' between layers? Also, each layer may need access to other information so that it knows how to deal with that data once it comes under its control.

The 3-tier architecture was promoted in the language I used prior to PHP as it made it possible to have an application with a client-server interface and to enable it for the web simply by adding on a new HTML interface which could share all the existing business and data access logic.

If they had near identical navigation and screens, then you did not change the presentation layer, all you did was port details of the front end.

I don't know where you get your ideas from, but changing the user interface from client-server to web most definitely IS a change in the presentation layer. One is stateful and uses a GUI interface, one is stateless and uses HTML and CSS as its interface. The two are totally different visually, and require totally different code to generate them. The fact that the two sets of screens are made to look as similar as possible is not only irrelevant, it is usually a user requirement as they do not want masive amounts of retraining in order to switch from one set of screens to the other.

[Captain Proton]

If the distinction between code that simply has classes and code that is object orientated is arbitrary to you, then you might want to take a second look at it.

Ok, you tell me: what exactly is the difference? By definition there is no difference: object oriented code is 'code that has classes' to put it loosely. I know what you're talking about though, in fact I have the same critique on a lot of code I see, but it is a subjective matter. I want to see an objective definition of OO that says I cannot just stick a bunch of functions into a class because it is not object oriented code any more.

Secondly, give me a definition of object oriented programming which requires more the code to be more than just consisting of classes. Not your definition, but the definition (rethorical question: is there any book, internet site, or whatever that gives such a good definition of what OOP is, instead of just some person's interpretation of what it should be?).

Thirdly (nitpicking), "orientated" means we're talking about Asia here. The correct term is "oriented".

If you put pure procedural code into an object, it is still procedural code.

By definition every function is procedural. Object methods are not any different from regular functions (*procedures*) with a hidden $this parameter. So, by what you are saying, if I stuff *any* function into a class, it is no longer object oriented? You might want to think about exactly what it is you are saying before you make such a statement.

Here is one definition [of encapsulation]...

One definition? So there is more than one definition?? So encapsulation can be something totally different, depending on what definition you decide to follow??? Ohh what a great concept encapsulation must be if it can mean anything to anyone!....

Precision of concepts is important, people! Please try to realise this! The very reason we are having this heated discussion is because 'our' whole foundation is imprecise, vague and ambiguous!! OOP has no clearly defined concepts and therefore anybody can and is free to interpret the interpretations of other people in a way that most suits their needs. Is that a bad thing, freedom of interpretation? Yes! In an exact science like computer science, which is what PHP and OOP are founded on (right?), precision is important!

Also, consider this (note that I said 'consider', which means 'think about it' and is not the same as 'I want you to accept this'): if OOP leaves open so many questions and has so many subjective sides to it, perhaps the model is just a bad model? It may have good sides (believe me, it does) but there are bad sides to it - which I hope I have shed some light on in this post..

End.

The M in MVC stands for "model". If they meant "database" they would have called it DVC.

The precision-of-definition argument is valid too, here. What is the definition of model? What is and what is not a model? Again this is a subjective thing. And subjective means that it is ambigous and therefore the very cause of the confusion that lays beneath this discussion!

My code contains all those features, therefore it is OO. It may not be your flavour of OO, but it is OO all the same.

That's what I am trying to explain in this post: that because OOP has no objective definition, it is ambigous and that will lead to several 'flavours' of it. Lastcraft's flavour, which is perhaps the general consensual flavour on this forum, may not be the same as Tony's, but Tony's code is no less OOP. Note that I am in no way saying that either one is better or they are equally good.

If not there are plenty of OO tutorials on the web which are also wrong.

Another critique on the subjective nature of OOP: each of those tutorials presents the interpretation of vague concepts by some author, a possible 'flavour' of OOP if you will. This is the cause of the confusion again.

Encapsulation is a language construct that facilitates the bundling of data with the methods operating on that data.

Great! "Encapsulation is a language construct", so that means encapsulation is something like if, else, foreach and while, right? Well since there is no such thing as "encapsulate { $var }" in any language, I assume the language construct intended here is the "class { }" construct, right? So according to this definition that means that *every* class is encapsulated! Do you see what a lousy definition this is?! The very first sentence of the so-called 'definition' is just plain wrong!

But of course if you view 'language construct' as a more broader concept, you can see just exactly what you want in this definition of encapsulation: ambiguity -> vagueness -> confusion!

[Tony Marston]

There are many ways to choose from, each with their own sets of advantages and disadvantages, and provided that the chosen method works and both the developers and the end users can live with the advantages and disadvantages, then all in the garden is rosy.

When combinations don't work well together then they just create extra work or problems. Your garden seems to have more than a few weeds. It might be time to break out the DDT.

Then you obviously have not run my code otherwise you would have noticed that the different components DO work well togther. I designed them that way specifically to avoid the problems I have encountered in other people's designs.

You haven't been vilified for your project at all. You have been rightly vilified for inflated claims and an insecure attitude.

I have never claimed anything that cannot be justified. I have developed an infrastructure that works, I have produced volumes of documentation, and I have made a sample available on my website which can either be run online or downloaded. I have never claimed that it can do anything which it does not actually do. I have never claimed that it is pure OO, just that it contains some components which are OO. I have never claimed that my design is the only 'true' design, nor have I claimed that my methods are the only 'true' methods. All that I have claimed is that they are 'different'. It is 'difference' which is the parent of innovation.

All your arguments seem to be based on the fact that my methods are different to yours, not that my results are any better (or worse) than yours. I am a pragmatist in that my primary concern is the result, and I will use or discard any methodology as I see fit in order to achieve that result. I will use or discard any set of arbitrary rules as I see fit in order to achieve that result. Where a definition is open to interpretation I will use whatver interpretation I see fit in order to achieve that result.

You, on the other hand, fit the classic description of a dogmatist - you think that following an arbitrary set of rules to the letter and without question is more important than obtaining the best result.

[Tony Marston]

How does that differ from the definition of encapsulation which I have previously quoted?

That definition does not explain why you should put everything related to a user in a single class.

Which part of:

Encapsulation rule 1: Place data and the operations that perform on that data in the same class.

do you not understand?

It is like saying that all the code in the application should go an an Application class.

A sensible person would not say that. An application is comprised of many different entities, and each entity requires its own class. That is exactly how my infrastructure is constructed.

[Helge]

People, there have been some comments here that are close to (or maybe over) the line. Negative comments and characteristics about other members are not tolerated at SitePoint Forums.

Here is quote from the guidelines that should be well known to all of you

DON'T ATTACK EACH OTHER
Don't attack others. Personal attacks on others will not be tolerated. Challenge others' points of view and opinions, but do so respectfully and thoughtfully ... without insult and personal attack.

If there is another incident this thread will have to be closed.

[Tony Marston]

People, there have been some comments here that are close to (or maybe over) the line. Negative comments and characteristics about other members are not tolerated at SitePoint Forums.

If I have said anything which can be construed as a personal attack on another member, then I apologise most profusely. I am merely attempting to defend my point of view after vitrioloc attacks by others.