#2 Extract the data layer

[Numiton]

Because of legacy reasons, access to the underlying database is not modularized. The business logic code is intermingled with data access logic.

The drawbacks of this approach include:
- lots of repeated SQL statements (263 SELECT statements): for instance whenever one needs some posts, a query is performed in place (203 references for gVars.wpdb.posts)
- support for only one database (MySQL)
- change of the database schema is very difficult to perform

The SQL statements do not use hardcoded table names. The names of tables are members of the org.numiton.nwp.wp_includes.wpdb class. "gVars.wpdb.posts" is the typical way of referencing the "nwp_posts" table.

The extraction of the data layer should be performed gradually, table by table (there are 10 tables):
- identify all SQL code using the table
- move the specific Java statement to a method of a dedicated class (e.g. PostsDAO)
- try to reduce the number of methods by parameterizing them

[Numiton]

The data layer should be extensible. Additionally to the default MySQL support, nWP should be able to run other databases too.