You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 byQuery
). Lets add simple example to illustrate this approach.The text was updated successfully, but these errors were encountered: