Nombre de la tabla de exposición y nombres de campo en la URL de solicitud

Me encargaron crear este componente de Joomla (sí, joomla; pero no está relacionado) y un profesor me dijo que debería hacer mi código lo más dinámico posible (un código que necesita menos mantenimiento) y evitar la codificación rígida. El enfoque que pensamos inicialmente es tomar parámetros de URL, convertirlos en objetos y pasarlos a consulta.

Digamos que queremos leer el hotel con la identificación # 1 en la tabla "hoteles". supongamos que la tabla tiene los campos "hotel_id", "hotel_name" y algunos otros campos.

Ahora, el enfoque que tomamos al hacer la cadena de consulta sql es analizar la solicitud de URL que se veía así:

index.php?task=view&table=hotels&hotel_id=1&param1=something&param2=somethingelse

y lo convirtió en un objeto PHP como este (se muestra en equivalente JSON, más fácil de entender):

obj = {
  'table':'hotel',
  'conditions':{
        'hotel_id':'1',
        'param1':'something',
        'param2':'somethingelse'
}

y la consulta SQL será algo como esto, donde las condiciones se enlazan y se agregan a la cadena donde el campo y el valor de la cláusula WHERE son la clave y el valor del objeto (aún en forma JSON para facilitar):

SELECT * FROM obj.table WHERE hotel_id=1 AND param1=something and so on...

El problema que me molestó fue la exposición del nombre de la tabla y los nombres de los campos en la URL de solicitud. Sé que plantea un riesgo de seguridad al exponer elementos que solo deberían verse en el lado del servidor. La solución actual que estoy pensando es dar alias a cada tabla y campo para el lado del cliente, pero eso sería una codificación difícil, lo que va en contra de su política. y además, si hiciera eso, y tuviera mil tablas alias, no sería práctico.

¿Cuál es el método adecuado para hacer esto sin:

codificación dura Mantenga el código como dinámico y adaptable

EDITAR

En cuanto a las consultas arbitrarias (olvidé incluir esto), lo que actualmente las detiene en el back-end es una función, que toma una referencia de un objeto codificado (más como un archivo de configuración que se muestra aquí), y analiza la url por seleccionando parámetros o uniéndolos.

La configuración se parece a:

// 'hotels' here is the table name. instead of parsing the url for a table name
// php will just find the table from this config. if no match, return error.
// reduces risk of arbitrary tables.

'hotels' => array(      

  // fields and their types, used to identify what filter to use

  'structure' => array(  
    'hotel_id'=>'int',
    'name'=>'string',
    'description'=>'string',
    'featured'=>'boolean',
    'published'=>'boolean'
  ),

   //these are the list of 'tasks' and accepted parameters, based on the ones above
   //these are the actual parameter names which i said were the same as field names
   //the ones in 'values' are usually values for inserting and updating
   //the ones in 'conditions' are the ones used in the WHERE part of the query

  'operations' =>array(  
    'add' => array(
      'values' => array('name','description','featured'),
      'conditions' => array()
    ),
    'view' => array(
    'values' => array(),
    'conditions' => array('hotel_id')
    ),
    'edit' => array(
    'values' => array('name','description','featured'),
    'conditions' => array('hotel_id')
    ),
    'remove' => array(
    'values' => array(),
    'conditions' => array('hotel_id')
    )
  )
)

y así, de esa lista de configuración:

si los parámetros enviados para una tarea no están completos, el servidor devuelve un error.si un parámetro de la url se duplica, solo se toma la primera lectura de parámetro. cualquier otro parámetro que no esté en la configuración se descarta si esa tarea no está permitida, no aparecerá en esa tablasi una tarea no está allí, el servidor devuelve un errorsi no hay una tabla, el servidor devuelve un error

Realmente diseñé esto después de ver un componente en Joomla que usa esta estrategia. Reduce el modelo y el controlador a 4 funciones dinámicas que serían CRUD, dejando solo el archivo de configuración como el único archivo editable más tarde (esto era lo que quise decir sobre código dinámico, solo agrego tablas y tareas si se necesitan más tablas) pero me temo que puede imponer un riesgo de seguridad que aún no conocía.

¿Alguna idea para una alternativa?