Data access layer: Difference between revisions

Revision as of 17:45, 30 December 2020

Revision as of 07:17, 7 September 2022

Line 3:

For example, the DAL might return a reference to an [[object (computer science)|object]] (in terms of [[object-oriented programming]]) complete with its attributes instead of a [[row (database)|row]] of [[Field (computer science)|fields]] from a database [[table (database)|table]]. This allows the [[Client (computing)|client]] (or user) modules to be created with a higher level of [[abstraction]]. This kind of model could be implemented by creating a class of data access methods that directly reference a corresponding set of database stored procedures. Another implementation could potentially retrieve or write records to or from a file system. The DAL hides this complexity of the underlying data store from the external world.

For example, instead of using commands such as ''insert'', ''delete'', and ''update'' to access a specific table in a database, a class and a few stored procedures could be created in the database. The procedures would be called from a method inside the class, which would return an object containing the requested values. Or, the insert, delete and update commands could be executed within simple functions like ''registeruserregister user'' or ''loginuserlogin user'' stored within the data access layer.

Also, business logic methods from an application can be mapped to the Data Access Layer. So, for example, instead of making a query into a database to fetch all users from several tables, the application can call a single method from a DAL which abstracts those database calls.