Why Phoebius?


Unified infrastructure

Standardised configuration

Phoebius framework defines a common file system layout and coding style, so applications based on it are meant to be similarly standardized.

Predictable control flow

An application logic is exception-centric: each PHP's error/warning/notice is replaced with the exception. Such a concept helps to avoid tons of unnoticeable inconsistencies (like an access to undefined index of an array) and thus making the usage of an internal PHP function strong enough and unambiguous. Of course, this functionality can be explicitly turned off when using a third-party library that does not know about the exceptions or ignores notices and warnings.

Though PHP is weakly-typed language, Phoebius framework propagates strong typing wherever possible to provide more stable and predictable code. Explicit and unambiguous type hints are specified in most of methods' signatures. Moreover, explicit type hints and type checks are used even for primitive build-in types (integer, boolean, etc) which allows to you define actions that accept external data of a narrow set of types.

Substitutable objects

Phoebius framework is testable, because being truly object-oriented application it minimizes the coupling between classes and provides the ability to substitute any object that is passed even into the framework internals. It is possible to integrate unit testing and examine a separate packages of Phoebius and an application based on Phoebius because of the great cohesion of interfaces; it is also possible to replace the contextual objects (e.g. WebRequest, IWebResponse) with your own implementations that produce custom results, log and check the calls and do anything you like.


Dealing with the complexity

Phoebius framework helps the developers to solve the tasks in context of project domain abstracting away from database tables and records. This dramatically increases the development process, due the logic of the code becomes simpler minimizing the number of bugs and reducing the time required for debugging: mostly-used operations, like constructing database queries or incoming data checks, are performed by the framework.

Project domain is the set of entities and their properties that describes a subject operated by a project. Entity is represented by an obvious PHP class that contains private properties of various types and the corresponding getters and setters. From now the development of an application becomes truly application programming, but not a low-level programming: you operate the essences of the real world instead of manipulating the database records.

Code generation

The project domain is used as a subject when generating the classes that implement lots of typical tasks varying from project to project:

  • querying entities against the used storage (typically, it is an RDBMS) and transparently mapping classes to the database schema of any complexity;
  • processing user input with automated forms that check incoming data against filters and then transparently map it to entities;
  • making a typification of incoming data from any source (e.g. XML to entities);
  • generating the standard websites with CRUD (create-read-update-delete) operations over defined essences.


Phoebius ORM abstracts away from the database records, giving only the PHP objects to a developer: project domain entities are classes, entity properties are classes too. Therefore the ability to implement different patterns of development becomes important. ORM itself can transparently map different database schemes to an obvious PHP classes:

  1. a column or even a set of columns to a class
  2. foreign keys (computed even by the set of columns) to an entity (1:1 relation)
  3. future version will support containers to an entry collections (both 1:* and *:* relations are supported and transparently handled by the framework from scratch)

Application flow

Phoebius MVC subsystem has an architecture similar to the ASP.NET MVC. By default it provides a ready-to-use toolset to make request handlers splitted into separate actions with automated casting of incoming parameters to even complex objects.

Separation of application logic and presentation is achieved by simple PHP-embed template engine - a simplified ASP.NET System.Web.UI implementation, which is able to link markup scripts with classes.

Routing package aims to provide a unified ability to rewrite and map requests to eliminate a necessity of using different webserver-specific tools (Apache mod_rewrite, nginx config, etc). It is needed to make a development process less obscure by using the object-oriented interface which features the independence from the environment (and thus the simplicity of deployment), possibility to test request matches, ability to create complex criteria of matching the requests (e.g. closures, etc), and implicitly map incoming data to classes. Moreover, it has a close integration with MVC so you can route requests directly to MVC actions/commands.