Jurnal de călătorie

lib/
   application/
   domain/
   infrastructure/
   presentation/
res/
   application/
   domain/
   infrastructure/
   presentation/
unit_testing/

The lib/ folder contains abstract classes and interfaces.

The res/ folder contains specific implementations of the previous ones.

On the next level, the folders mainly share the same structure, which probably will be familiar to people having worked with similar web-development frameworks. There are however a couple of differences between them. Namely the library folder and all its subfolders also contain some exceptions related to the code in that specific module.

In the resources folder there is a subfolder containing basic output templates to be used by MVC views. On these I'll come back a bit later.

On the right hand side you can see a basic representation of the structure of the library and resources folders. In the next couple of paragraphs I'll be talking a bit about the purpose of each of them.

application

The application folder contains objects related to the Controller section of the MVC pattern. Unlike the standard MVC, in libVSC the Controllers have been split into two sections, one of them named Front Controller conceptually is more a part of a View as it deals with the types of output. The second one, named the Processor, is what can be considered a traditional controller, as it the section that feeds input into the logic layer of libVSC, the Model entity, and returns these models to the Front Controllers and Views to be displayed to the user.

The dispatcher and sitemap sections of the application module, contain objects related to the dispatching of view/request objects. Mainly they contain some logic processors for computing relations between GET requests to sections of your application. The actual logic of this mapping should be included in the sitemap files your application needs.

domain

This module consists of the Model related objects from MVC and provides uniform methods for accessing different types of data. It is separated in three submodules, which deal with the following parts of creating a data model.

Access contains objects which provide the means to interface with the persistent storage layer of your application, which can be a database, a flat text file, a json file, etc.

The domain submodule contains the actual entities that the model is based on top of. In the case of databases they abstract a table. In the case of a Json file, they contain the structure representation of a specific json object.

The model submodule contains the objects which actually interact with the other layers of the MVC. Namely they consist of business logic based on top of input received from the Processor and are used by the View to output the processed data.

infrastructure

This module contains objects which are not actually part of the MVC paradigm, but are used in one way or another by libVSC. As an example, most of the objects of libVSC are built on top of a basic vscObject which provides some fallback mechanisms in case of errors. On the vscNull and vscObject classes I'll come back at a later date.

presentation

The presentation layer has three main submodules. Two of them contain object wrappers for standard HTTP request and responses. The third one contains a simple View submodule, which is similarly built as Smarty just interprets standard PHP templates. Unlike Smarty, the templates are built with plain PHP as I don't think it's really necessary to invent a whole new language just for template output.

templates

In the resources folder, we have some basic templates used by libVSC. They are separated by mime-type and are used mainly for default responses, like 404.