#2 Extract the data layer

open
nobody
5
2008-10-08
2008-10-08
Numiton
No

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

Discussion

  • Numiton

    Numiton - 2008-10-08

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

     
  • Numiton

    Numiton - 2008-10-08
    • summary: Extract data layer --> Extract the data layer
     

Log in to post a comment.