# Introduction

Tonka aims to be much more pragmatic with the idea of ​​serving not only as a development tool but also as a real direct testing tool; in the feeling of providing the same results as a manual test in the browser. It would therefore not be a question of unit tests, which only test the logic of the code and are more cumbersome, but a global test much more focused on the stability of the code. So Tonka wants to make you feel like a superhero who dictates his will to the code and not the other way around. In the sense that it gives you control over data input from its reception to its storage.

Tonka has an ORM (Object Relational Model) which has nothing to envy of either Eloquent or Doctrine. Its uniqueness lies in its ability to manage any kind of query to the database with much less abstraction, that is to say the communication is done as one would feel when writing direct SQL queries to the database. Tonka ORM does not limit you to so-called standard modes of use, but rather it lets you create your own standard. Moreover, it does not stop there, it attacks security with a ferocity that even the most gifted hacker would fear. Because Tonka doesn't leave the tedious task of security to the database driver, but rather it takes over the task by letting you dictate precisely the types of data you want to receive using custom validators .

To achieve this, data can be validated from the router to database entities before storage. Although Tonka only has one validation module. That is, the same validator is used on the route, on the controller and on the entity attributes. Imagine if data was validated three times, would it escape the radar? However, this is not a Tonka standard. If you are sure of your validator you can do it in one specific place.