Designing Data Tier Components
When designing a distributed application,
you need to decide how to access and represent the business data associated
with your application. This Session provides guidance to help you choose
the most appropriate way of exposing, persisting and passing that data
through the tiers of an application.
Picture A depicts the common tiers
of a distributed application. This Session distinguishes between business
data and the business processes that use the data; the business process
tier is discussed only where needed for clarification. Likewise, the presentation
tier is discussed only where there are direct implications for the way
data is represented, such as the way Microsoft ASP.NET Web pages expose
business data. Picture A introduces two new terms: data access logic components
and business entity components.
Picture A. Accessing and representing
data in a distributed application
Most applications store data in
relational databases. While there are other options for storing data, This
Session focuses on how .NET applications interact with relational databases,
and does not specifically discuss how to interact with data held in other
data stores such as flat files or non-relational databases.
This Session makes a clear distinction
between persistence logic and the data itself. The reasons for separating
persistence logic from the data include the following:
Separate
data persistence components can isolate the application from database dependencies,
such as the name of the data source, connection information and field names.
Many
of today's applications use loosely coupled, message-based technologies,
such as XML Web services and Microsoft Message Queuing (also known as MSMQ).
These applications typically communicate by passing business documents,
rather than by passing objects.
To attain the distinction between
persistence logic and the data itself, This Session proposes two different
component types.
Data
access logic components. Data access logic components retrieve data from
the database and save entity data back to the database. Data access logic
components also contain any business logic needed to achieve data-related
operations.
Business
entity components. Data is used to represent real world business entities,
such as products or orders. There are numerous ways to represent these
business entities in your applicationfor example, XML or DataSets or
custom object-oriented classesdepending on the physical and logical design
constraints of the application. Design options are investigated in detail
later in This Session.
Data Access Logic Components
A Data Access Logic Component provides
methods to perform the following tasks upon a database, on behalf of the
caller:
Create
records in the database
Read
records in the database, and return business entity data to the caller
Update
records in the database, by using revised business entity data supplied
by the caller
Delete
records in the database
The methods that perform the preceding
tasks are often called "CRUD" methods, where CRUD is an acronym
based on the first letter of each task.
The Data Access Logic Component
also has methods to implement business logic against the database. For
example, a Data Access Logic Component might have a method to find the
highest-selling product in a catalog for this month.
Typically, a Data Access Logic
Component accesses a single database and encapsulates the data-related
operations for a single table or a group of related tables in the database.
For example, you might define one Data Access Logic Component to deal with
the Customer and Address tables in a database, and another Data Access
Logic Component to deal with the Orders and OrderDetails tables. The design
decisions for mapping data access logic components to database tables are
discussed later in This Session.
DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services Limited. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services limited on any subject matter.
Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services Limited takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services limited shall be understood as neither given nor endorsed by Tata Consultancy Services Limited or any affiliate of Tata Consultancy Services Limited. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail.
Thank you.
|
| 
