Database Reference
In-Depth Information
The Business Logic Layer contains the set of business objects that represent the business
entities in the system, and it implements business logic and workflow. Usually, it is a good
practice disconnecting business objects from the data using lightweight Data Transfer
Objects (DTO) for communication. However, it is not uncommon to see business objects
working with the data directly, especially in smaller systems.
The Data Access Layer is responsible for dealing with the data. It serves as a gateway
between the data sources and other subsystems, abstracting data location and schema.
As already mentioned, it usually uses DTO objects to pass the data to or accept data from
the Business Logic Layer. It is also entirely possible that the data access layer crosses the
boundaries of the application code and uses stored procedures or database views as
another layer of abstraction.
One of the key elements in this design is the separation of business objects from a database schema. The
relational data model in the database is different from the object-oriented programming model by nature. Database
tables should never be created with the goal of matching class definitions in the application.
even though SQL Server allows you to emulate pseudo-object oriented databases and use CLr user-defined
types that store .net business objects, it is an extremely bad idea. Doing so introduces supportability issues due to the
inability to alter the type interfaces. it complicates access to the data and lowers system performance when compared to
a classic relational implementation.
Note
I would like to re-iterate a key point here. Physical separation of the layers in the system is less important than
logical separation . The latter separation, when it is done the right way, reduces the cost of code refactoring by
localizing the parts of the code that need to be changed.
Consider the situation where you need to change a data type of one of the columns in the database table. That
change, in turn, requires modification of the application code that references the table. With layered architecture,
the task is very simple, and all of the changes are localized in the data access and business logic layers. Even though
other layers of the system could reference business objects and require some refactoring, you would be able to find
references on the compilation stage, and the application would not compile due to data type mismatches. Last, but
not least, all those changes can be done by the team of database and/or backend developers transparently to other
teams and often deployed separately from other system components.
Spaghetti-like code that accesses the database from all over the place is another story. You will need to find all
of the references to a particular database object in the code and change them. That situation is prone to errors, and it
can lead to massive disruption for all of the developers on the team.
The choice of the data access technology affects other components in the system, and it should be done at the
initial system design stage. Let's look in depth at several common approaches.
Data Access Layer Design
Every client application that works with databases has a data access layer, even if it is not formally defined. In simple
cases, the data access layer is implemented with regular DML queries against database tables. In more complex
situations, client applications can work with the data through the layer of stored procedures and/or views, or they can
utilize ORM frameworks and/or code generators.
As usual, the answer to the question “How should the data access layer be implemented?” is in “It Depends”
category. Each approach comes with a set of benefits and limitations, and each has an implementation cost.
Moreover, you can combine different techniques when needed. For example, systems that use ORM Frameworks can
call stored procedures for performance-critical use cases.
 
 
Search WWH ::




Custom Search