Business object is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing detains of the database. It provides a mapping from application calls to the persistence layer. For e.g to build an Employee business object a developer would write an Employee class which contains attributes for each field in the Employee table. The Employee class finally uses some ADO.NET code to perform the operations like insert, update, select and delete rows from the employee table.
This type of an approach requires large volume of implementation code to be written that requires understanding of the database schema. This introduces an impedance mismatch which is a set of conceptual and technical difficulties that are encountered when database tables or relational schema is mapped into objects or classes.
Object relational mapping (ORM) is a mechanism that makes it possible to access and manipulate objects without having to consider how those objects relate to their data sources. ORM helps programmers by providing the technique for converting data between incompatible type systems in relational databases and object oriented programming languages. ORM hides and encapsulates change in the data source itself, so that when data sources or their APIs change, only ORM needs to change to keep up-not the applications that use ORM to insulate themselves from this kind of effort.
With a variety of O/R frameworks available today, we have a wide range of choices to use. For this article series I’ll focus on NHibernate, an open source solution available. With NHibernate your code and data schema remain decoupled and the only visible indicator of the existence of the OR layer are the mapping files. NHibernate uses configuration settings mentioned in these mapping files to map the business objects to the data tables.
No comments:
Post a Comment