Download Camadas I

Application Layers and
Tiers
Arquitectura de uma Aplicação
1
Layers and Tiers
A organização do software em camadas permite estruturar as
aplicações em grupos de subtarefas onde cada grupo
corresponde a um determinado grau de abstracção.
Separa as várias tarefas da aplicação ou sistema: aceder a
dados, armazenamento de dados, execução de regras de
negócio, apresentação da informação, etc.
Layer é uma separação lógica de componentes de software,
ao nível do desenvolvimento, de modo a tornar mais simples a
partição de responsabilidades e tarefas de um sistema
Tier, é uma camada de hardware físico, normalmente um
computador, onde o software é executado.
A arquitectura cliente/servidor básica é um sistema “two-tier” :
programa que executa SQL numa base de dados a correr num
servidor separado.
2
Layer and Tiers
Organização em camadas
Layer 3
O layer de nível superior usa vários serviços
definidos no layer de nível inferior, mas o
layer mais a baixo desconhece ( não
depende) do nível superior.
Layer 2
Cada layer, normalmente, esconde os seus
níveis inferiores dos seus layers de nível
superior – layer 3 usa serviços do layer 2 ,
que por sua vez usa serviços do layer 1, mas
o nível 3 não conhece o nível 1 ( nem sempre
é tão rigoroso).
Layer 1
3
Layers and Tiers
Vantagens
You can understand a single layer as a coherent whole without
knowing much about the other layers. You can understand how to
build an FTP service on top of TCP without knowing the details of
how ethernet works.
You can substitute layers with alternative implementations of the
same basic services. An FTP service can run without change over
ethernet, PPP, or whatever a cable company uses.
You minimize dependencies between layers. If the cable company
changes its physical transmission system, providing they make IP
work, we don't have to alter our FTP service.
Layers make good places for standardization. TCP and IP are
standards because they define how their layers should operate.
Once you have a layer built, you can use it for many higher-level
services. Thus, TCP/IP is used by FTP, telnet, SSH, and HTTP.
Otherwise, all of these higher-level protocols would have to write
their own lower-level protocols.
[Patterns of Enterprise Application Architecture – Martin Fowler]
4
Arquitectura de três camadas (3-layer)
5
Organização em três camadas principais
Presentation (UI)
Apresentação da informação aos utilizadores e
interpretação de comandos realizados pelo utilizador em
acções para as camadas inferiores.
Domain logic (business logic)
Parte da aplicação ligada ao dominio do problema. Involve,
p.e, cáculos baseados na entrada e armazenamento dos
dados, validação da informação e determinação da fonte de
dados a usar. Representação de entidades de negócio
como produtos, encomendas, etc.
Data source
Camada para aceder, inserir, alterar a informação e usar
outros serviços.
6
Layered Application
Localizing changes to one part of the solution minimizes the
impact on other parts, reduces the work involved in debugging
and fixing bugs, eases application maintenance, and enhances
overall application flexibility.
Separation of concerns among components (for example,
separating the user interface from the business logic, and
separating the business logic from the database) increases
flexibility, maintainability, and scalability.
Components should be reusable by multiple applications.
Independent teams should be able to work on parts of the
solution with minimal dependencies on other teams and should
be able to develop against well-defined interfaces.
Unrelated components should be loosely coupled.
Various components of the solution are independently deployed,
maintained, and updated, on different time schedules.
7
Layered Application
Some downsides
Crossing too many component boundaries has an adverse
effect on performance.
The extra overhead of passing through layers instead of
calling a component directly can negatively affect
performance. To help offset the performance hit, you can use
the relaxed layers approach, in which higher layers can
directly call lower layers.
Development of user-intensive applications can sometime take
longer if the layering prevents the use of user interface
components that directly interact with the database.
The use of layers helps to control and encapsulate the
complexity of large applications, but adds complexity to
simple applications.
Changes to lower-level interfaces tend to percolate to higher
levels, especially if the relaxed layered approach is used.
8
Layered Application
Example
9
Projecto de Componentes da Camada de
Acesso a Dados
http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Ambientes de Desenvolvimento Avançados
Prof. José Reis Tavares
- http://www.dei.isep.ipp.pt/~jtavares/ADAV/ADAV.htm
10
Conteúdo
Introdução
Componentes Lógicos de Acesso a Dados
Representação de Entidades de Negócio
Mapeamento de Dados Relacionais a Entidades
de Negócio
Implementação de Componentes Lógicos de
Acesso a Dados
Implementação de Entidades de Negócio
11
Introdução
Camadas comuns numa
aplicação distribuída
12
Componentes Lógicos de Acesso a Dados (DALC)
Data Access Logic Component (DALC) provides
methods to perform the following tasks upon a
database:
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.
13
DALC
The methods that perform the preceding tasks
are often called “CRUD” methods;
CRUD is an acronym based on the first letter of
each task
The DALC also has methods to implement
business logic against the database.
Ex: a DALC might have a method to find the
highest-selling product in a catalog for this
month.
14
DALC
Typically, a DALC accesses a single database
and encapsulates the data-related operations for
a single table or a group of related tables in the
database.
Ex: you might define one DALC to deal with the
Customer and Address tables in a database, and
another DALC to deal with the Orders and
OrderDetails tables.
15
Representação de Entidades de Negócio
Each DALC deals with a specific type of
Business Entity (BE).
For example, the Customer DALC deals with
Customer BE.
There are many different ways to represent BE,
depending on different factors:
16
Representação de Entidades de Negócio
Such factors are as the following:
need to bind BE data to controls in a WinForm or on a
ASP.NET page?
need to sort or search operations on the BE data?
application deals with BE one at a time, or does it
typically deal with sets of BE?
deploy your application locally or remotely?
will the BE be used by XML Web services?
how important are nonfunctional requirements, such
as performance, scalability, maintainability, and
programming convenience?
17
Representação de Entidades de Negócio
Technical
considerations that
influence the design of
data access logic
components and
Business Entities
18
Mapeamento de Dados Relacionais a Entidades de Negócio
An hypothetical retailer’s database
Databases typically contain many tables,
with relationships implemented by primary
keys and foreign keys in these tables. When
you define BE to represent this data in your
application, you must decide how to map
these tables to BE.
19
Mapeamento de Dados Relacionais a Entidades de Negócio
Typical operations in the hypothetical retailer’s
application are as follows:
Get (or update) information about a customer,
including his or her addresses.
Get a list of orders for a customer.
Get a list of order items for a particular order.
Place a new order.
Get (or update) information about a product or a
collection of products.
20
Mapeamento de Dados Relacionais a Entidades de Negócio
There
are three logical BE that the application will handle: a
Customer, an Order, and a Product.
For
each BE, a separate DALC will be defined, as follows:
Customer
DALC. This class will provide services to
retrieve and modify data in the Customer and Address
tables.
Order
DALC. This class will provide services to retrieve
and modify data in the Order and OrderDetails
tables.
Product
DALC. This class will provide services to retrieve
and modify data in the Product table.
21
Mapeamento de Dados Relacionais a Entidades de Negócio
The relationships between the data access logic components and
the tables that they represent in the database.
22
Recomendações para mapear dados relacionais com
entidades de negócio
Take the time to analyze and model the logical BE of your
application, rather than defining a separate BE for every
table. One of the ways to model how your application
works is to use UML.
Do not define separate BE to represent many-to-many
tables in the database; these relationships can be exposed
through methods implemented in your DALC.
EX: the OrderDetails table in the preceding example is not
mapped to a separate BE; instead, the Orders DALC
encapsulates the OrderDetails table to achieve the manyto-many relationship between the Order and Product tables.
23
Recomendações para mapear dados relacionais com
entidades de negócio
If you have methods that return a particular type
of BE, place these methods in the DALC for that
type.
EX: if you are retrieving all orders for a customer,
implement that function in the Order DALC because
your return value is of the type Order. Conversely, if
you are retrieving all customers that have ordered a
specific product, implement that function in the
Customer DALC.
DALC typically access data from a single data
source. If aggregation from multiple data
sources is required, it is recommended to define
a separate DALC to access each data source.
24
Implementação dos Componentes Lógicos de Acesso a Dados
A DALC is a stateless class, meaning that all
messages exchanged can be interpreted
independently.
DALC provides methods for accessing one or more
related tables in a single database, or in some
instances, multiple databases as in the case of
horizontal database partitioning.
Typically, the methods in a DALC invoke stored
procedures to perform their operations.
25
Implementação dos Componentes Lógicos de Acesso a Dados
One of the key goals of DALC is to hide the invocation and
format idiosyncrasies of the database from the calling
application.
Specifically, a DALC handle the following implementation details:
Manage and encapsulate locking schemes
Handle security and authorization issues appropriately
Handle transaction issues appropriately
Perform data paging
Perform data-dependent routing if required
Implement a caching strategy if appropriate, for queries of
nontransactional data
Perform data streaming and data serialization
26
Cenários para os
DALC
DALC can be called
from a variety of
application types:
• Windows Forms
applications,
• ASP.NET applications,
• XML Web services
• Business processes.
These calls might
be local or remote,
depending on how you
deploy your applications.