OOP Organizing an application in OOP

PHP
1

I’m pretty clear on the basics of OOP. What I have not found is a good discussion of how to organize a whole web-app as an OOP object. Stand alone objects are simple enough. Groups of objects (Animal, Cat, Dog. Lion) are simple enough. Utility functions can be grouped into abstract classes (HTML, CSS, Math). The difficulty I have is in organizing it all into an object which is a pyramid several levels deep which is where the dependency injection container concept comes into play.

One simple solution for me would be to write a bunch of classes as needed but to call them from a procedural script. It seems to me I would be reaping many of the benefits of OOP while avoiding the complications.

I’ve been Googling for papers on how to organize a whole app with objects but I have not found one that discusses the subject at that level. There are lots of beginner’s papers and lots of technical papers but none that discuss the architecture of an OOP web-app. Can anyone point me to one? It would be much appreciated. :slight_smile:

2

Here are a couple articles that may help.

From Flat PHP to Symfony2 takes you step by step from a traditional procedural page to MVC* to OOP components.

And reading how the Symfony2 HttpKernel works may give you ideas and inspiration.

* That is, MVC as it’s typically conceived by web applications

3

Hey captainccs,

How familiar are you with existing web frameworks, and patterns like MVC and Front Controller etc?

Edit: Just seen Jeff’s post… I’d second reading that Flat file to Symfony article… it’s a really good explanation of the how and why to go from the usual all-in-one procedural scripts to something OO and framework-based

4

Wikipedia gave me one of the best answers yet!

Symfony is a web application framework written in PHP that follows the model–view–controller (MVC) paradigm. Released under the MIT license, Symfony is free software. The symfony-project.com website launched on October 18, 2005.[1]

I’m not familiar with the usual frameworks. I’ve built my own which is essentially MVC but organized differently. I have a real html page for each html url so I don’t need to rewrite links with htaccess but the html pages are just “design shells”

<?php include "controller"; ?> 
<!doctype html>
<html>
<!-- more html tags -->
<?php include "view"; ?> 
<!-- more html tags -->
</html>

I don’t really want to change this. I want to move the “application_logic” to OOP.

Edit: Just seen Jeff’s post… I’d second reading that Flat file to Symfony article… it’s a really good explanation of the how and why to go from the usual all-in-one procedural scripts to something OO and framework-based

I just read the piece. I’ve already done the “all-in-one procedural scripts to procedural framework.”
Unfortunately when it got to Symphony it stopped talking architecture and started in on the nitty gritty of Symphony.

Considering the Wikipedia quote I’m probably best off to just convert my current framework to OOP. I’ve already done a few helper classes like Database. Recently I read a discussion about how to model your classes. On one side they were recommending modeling the classes on the “real world” and on the other modeling them just to organize the code. This was before I got into the architecture question and “real world” sounded very reasonable. But now I’m changing my tune, the principal classes should be the controller or controllers and the views. That’s much less difficult to model than the real world.

Am I making sense? :wink:

5

OO I’m in trouble now: :smiley:

Fabien Potencier – Symfony Is NOT A MVC Framework

http://object-oriented-php.com/2011/10/fabien-potencier-symfony-is-not-a-mvc-framework/

6

Indeed.

The original definition of MVC was written with desktop applications in mind, and it doesn’t translate perfectly to stateless, server-side web applications. For example, MVC controllers are supposed to handle user input – such as mouse clicks, key presses, touches, gestures, device orientation, etc – and translate that input into commands for the view and the model. But in server-side web applications, there’s only one input: the HTTP request. Also, MVC views are supposed to be able to react to user input as well as to changes in the model, but in server-side web applications, there won’t be any new user input for the view to react to, nor will there be any changes in the model that would require the view to update itself.

That’s why I put the asterisk next to MVC in my post above. Fabien has called Symfony2 a Request-Response framework, because that’s how the web works.

Though, the term “MVC” still gets used a lot. It would seem that the new, web-specific definition of MVC is here to stay.

7

This is the kind of thing I was looking for!

The MVC model

Today will be the first dive in the world of the MVC architecture. What does this mean? Simply that the code used to generate one page is located in various files according to its nature.

If the code concerns data manipulation independent from a page, it should be located in the Model (most of the time in askeet/lib/model/). If it concerns the final presentation, it should be located in the View; in symfony, the view layer relies on templates (for instance in askeet/apps/frontend/modules/question/templates/) and configuration files. Eventually, the code dedicated to tie all this together and to translate the site logic into good old PHP is located in the Controller, and in symfony the controller for a specific page is called an action (look for actions in askeet/apps/frontend/modules/question/actions/). You can read more about this model in the MVC implementation in symfony chapter of the symfony book.

8

Yeah, as that article points out, people like to argue over different flavours of MV* (MVC, MVP, MVVM… plenty of acronyms get bandied about), but I think the key point (which it also mentions) is the separation of concerns…

Absolutely, that was something I that used to confuse me too… I think it’s helpful to think about your app in two parts: the ‘domain objects’, the classes which make up your business logic and entities, and the ‘infrastructure’ classes which hold your application logic. Your domain model can be modelled after the real world, and that makes sense… in the case of your Condo app you might have classes representing condos, units, owners, tenants etc. On the other hand, your controller classes and stuff like that obviously don’t reflect a real world object, so you’d divide up into classes that make the most sense in terms of responsibilities and re-usability

9

Why would you want to do that? It seems that you’re making more work for yourself just to avoid a couple lines in your .htaccess file.

10

It has nothing to do with avoiding htaccess and everything to do with how the project was born. I had a designer friend, unfortunately he died, who needed someone to do the back end of his web designs. The way we worked together my code hardly interfered with his Dreamweaver stuff. Each of his designs was unique and he never used templates, it was all original art.

The framework that evolved has a logic file (controller?) for each application, there can be more than one per website. Each application has its database file and each web page has its “view” module. The “model” part is not clearly separated. One could make it work AJAX style too.

In fact the amount of work to have individual pages is quite small.

11

Could you talk through how that works at the moment? You say that you want to move your application logic to OO code, so what would happen in your app at the moment if I visit a page that displays info for a particular ‘thing’ (can be a condo, or whatever you like). I’m interested to know how you’ve currently got your app logic arranged.

12

Omitting some detail here is how it works

At the top of each page I include the app’s logic, a php page.

<php $include = "/path/to/scripts/";
include "{$include}app-logic.php" ?>

The app’s logic (controller) includes all the required files.

Then a big switch takes over

<php switch ($action) {} ?>

The $action variable is populated by either a $_POST or a $_GET

Then the page HTML is served. Inside the body is another include

<php include "{$app_module}app-module.php" ?>

app-module.php does the business logic (model) and renders the view.

the rest of the HTML is served and the server is done.

All the sql is in a separate sql.php file (one per app). Passwords and other variables are in a setup.php file (one per app).

The app-module.php page is often also a big switch so that it can display a form on first entry, a review page (which is really a hidden form) or error or other feedback. By always using

<form action="<?php echo $_SERVER['PHP_SELF']; ?>"

the pages can be moved around from directory to diretory with no ill effect.

If I have a password protected page then two apps run, the app proper and the members app. An if clause in the app-module.php page determines which is rendered, the page or the login form.

With the switches everything is pretty modular.

That’s about it. Here it is live:

Edit: BTW, you can run any number of apps in the same page, each one displays in its own div. You include the logic for all of them at the top and the views in the various divs.

13

@captaincss;

I have been using CodeIgniter for quite a number of years. It is robust, small, quick, with excellent documentation and best of all with a nooby friendly forum.

I think it will be a good introduction to other PHP Frameworks which seem to have similar structures. I think that your working method will easily fit into the CodeIgniter’s preferred method.

http://ellislab.com/codeigniter/user-guide/overview/appflow.html

I have also played with a few other frameworks and keep on coming back to CodeIgniter :slight_smile:

14

John:

Thanks but I’m not looking to use a framework but to build one. Or rather, to convert mine to OOP. This is a learning exercise. :wink:

15

The idea of looking at other frameworks is for the layout and how they separate the system core libraries, etc which makes upgrades simple. All that is required is to download source, upload to your online site then change a single line in the online root index.php file.

As mentioned I like the CodeIgniter approach and it is oh so easy. A new project can be created and up and running online in less than ten minutes.

16

John:

Sorry I misunderstood. I’ve taken a first look at Codeigniter.

Apparently these frameworks all reinvent what html does naturally, display pages. I’m quite happy to let html do that. I just want my framework to build the content for the pages. :wink:

I’m going to take a look at how they build dynamic pages.

17

Take another look at the link to the Flow Chart Diagram in my previous post.

This link to the calendar view maybe helpful. It is populated from the Calendar Controller, etc:

18

John:

Can you tell me what database name Codeigniter expects? I created one called “codeigniter” but it does not work

Unable to connect to your database server using the provided settings.

Filename: core/Loader.php

Line Number: 346

Edit: Found it!

19

Try including this file at the end of your application/config/database.php

I always use this test file to produce verbose database connection details when the database connection fails.

20

Thanks, I’ve finished the tutorial, the rest is going to keep me busy for a while!

:wink: