Sometimes access to the database records should be controlled on a data layer. Typical situations:
SaaS applications that use single database for all "instances"; in this case data is isolated by adding something like "instance_id" or "client_id' in all tables. Data layer should guarantee that business logic will able to select/update/delete records only of the current "instance".
business apps where access to the records is controlled by some rules. For instance, someone should able to select a record only if it is "assigned" to this record.
NReco.Data supports this kind of access control; it is possible to add extra 'access control' conditons to the Query before execution by wrapping IDbCommandBuilder (responsible for ADO.NET commands generation by Query). Lets add simple example to illustrate this approach.
Sometimes access to the database records should be controlled on a data layer. Typical situations:
SaaS applications that use single database for all "instances"; in this case data is isolated by adding something like "instance_id" or "client_id' in all tables. Data layer should guarantee that business logic will able to select/update/delete records only of the current "instance".
business apps where access to the records is controlled by some rules. For instance, someone should able to select a record only if it is "assigned" to this record.
NReco.Data supports this kind of access control; it is possible to add extra 'access control' conditons to the
Querybefore execution by wrapping IDbCommandBuilder (responsible for ADO.NET commands generation byQuery). Lets add simple example to illustrate this approach.