PROGRAMACION

ORIENTADA A OBJETOS II
CD. 11.55.305
https://sites.google.com/a/ufps.edu.co/borisperezg

UNIDAD 3: ARQUITECTURA DE TRABAJO

Capa del Negocio

Capa DTO
Capa DAO
Capa de u,lidades
Capa de presentacin
Excepciones

UNIDAD 3 ARQUITECTURA DE
TRABAJO
INTRODUCTION

Applica,ons are broken down into a series of layers. We consider a layer to be a discrete, orthogonal area of
concern within an applica,on. For instance, all of the persistence code is considered a separate layer from the view
rendering code. Layers are abstrac,ons within an applica,on, and interfaces provide the contract by which layers
interact. Some layers might be well hidden, used only by the layer immediately above it. In contrast, the most
important layer (the domain model itself) spans nearly all the other layers in the system.

Layers are conceptual boundaries and are not necessarily physically isolated. More oKen than not, all of the layers
will be located within the same virtual machine for a web applica,on.

Thinking in layers can help conceptualize the ow through an applica,on. Visualizing the applica,ons layers as a
cake (layers of cake stacked one on another) is a common and convenient way to illustrate how the applica,on is
organized. Typical metaphors such as down into persistence and back up to the user interface refer to a cake,
and denote a sense of ver,cal direc,on, reinforcing the metaphor.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
INTRODUCTION

Note: Are layers the same thing as ,ers? Many people use the two terms interchangeably, but separa,ng the two
helps when discussing the applica,on and its deployment. A layer is a logical abstrac,on within an applica,on. A
,er is best thought of as a physical deployment of the layers. Thinking in layers can help the soKware developer,
while thinking in ,ers can assist the system administrator. Layers are mapped onto ,ers.
















Typically, any persistence func,onality is at the boSom of the cake, while
the user interface is at the top.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
INTRODUCTION

Layer IsolaKon

Isola,ng problem domains, such as persistence, web naviga,on, and user interface, into separate layers creates a
exible and testable applica,on. Implementa,ons of each layer will vary independently, increasing the exibility of
the applica,on. Decreasing the coupling between areas of the applica,on will increase the testability, making it
easier to test each part of the applica,on in isola,on.

This isola,on is accomplished by minimizing the amounts of dependencies between the layers. The fewer
dependencies a layer has upon itself, the less costly it is to change that layer. It is a best prac,ce to ensure that a
layer is required only by one or two other layers. Avoid having
one single layer required by many dierent parts of
the applica,on.

You can avoid dependency explosion in at least two ways. If a layer begins to employ too many layers, consider
crea,ng a new layer of abstrac,on wrapping all the previous interac,ons.

The important point to remember is that one of the great benets of layering an applica,on is it creates a
decoupled design. When you discover a layer or facet of the applica,on that is too intrusive, refactor it to another
abstrac,on or through AOP. This will keep your applica,on exible and testable

AOP Aspect Oriented Programming

UNIDAD 3 ARQUITECTURA DE
TRABAJO
INTRODUCTION

Layer IsolaKon

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Business logic or domain logic is the part of the program that encodes the real-world business rules that determine
how data can be created, displayed, stored, and changed.

Business logic:

Models real life business objects (such as accounts, loan, i,neraries, and inventories)
Prescribes how business objects interact with one another
Enforces the routes and the methods by which business objects are accessed and updated

Business logic comprises:


Business rules that express business policy (such as channels, loca,on, logis,cs, prices, and products); and
Workows that are the ordered tasks of passing documents or data from one par,cipant (a person or a
soKware system) to another.

For example, an e-commerce website might allow visitors to add items to a shopping cart, specify a shipping
address, and supply payment informa,on. The business logic of the website might include rules like:

Adding an item more than once from the item descrip,on page increments the quan,ty for that item.
Specic formats that the visitor's address, email address, and credit card informa,on must follow.
The sequence of events that happens during checkout, for example allowing the billing address to be copied
from the shipping address already supplied.
A specic communica,on protocol for talking to the credit card network

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Business logic oKen changes. For example, the set of allowable address formats might change when an online

retailer starts shipping products to a new country. Thus it is oKen seen as desirable to make the code that
implements the business logic rela,vely isolated, or loosely coupled. This makes it more likely that changes to
business logic will require a small set of code changes, in only one part of the code. Distant but strongly coupled
code also creates more of a risk that the programmer will only make some of the necessary changes and miss part
of the system, leading to incorrect opera,on.

A mul,,er architecture formalizes this decoupling by crea,ng a business logic layer which is separate from other

,ers or layers, such as the data access layer or service layer. Each layer "knows" only a minimal amount about the
code in the other layers - just enough to accomplish necessary tasks. In the e-commerce example, the controller
determines the sequence of web pages in the checkout sequence, and is also responsible for valida,ng that email,
address, and payment informa,on sa,sfy the business rules (rather than leaving any of that up to the database
itself or lower-level database access code).

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

The facade paSern is a Gang of Four design paSern. This is a structural paSern as it denes a manner for crea,ng
rela,onships between classes or en,,es. The facade design paSern is used to dene a simplied interface to a
more complex subsystem.

GoF deni,on for facade design paSern is, Provide a unied interface to a set of interfaces in a subsystem. Facade
PaSern denes a higher-level interface that makes the subsystem easier to use.


How do we infer the above deni,on? Think of a component that solves a complex business problem. That
component may expose lot of interfaces to interact with it. To complete a process ow we may have to interact
with mul,ple interfaces.

To simplify that interac,on process, we introduce facade layer. Facade exposes a simplied interface (in this case a
single interface to perform that mul,-step process) and internally it interacts with those components and gets the
job done for you. It can be taken as one level of abstrac,on over an exis,ng layer.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

Facade design paSern is one among the other design paSerns that promote loose coupling. It emphasizes one
more important aspect of design which is abstrac,on. By hiding the complexity behind it and exposing a simple
interface it achieves abstrac,on.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

Real World Examples for Facade PaSern

Lets take a car, star,ng a car involves mul,ple steps. Imagine how it would be if you had to adjust n number of
valves and controllers. The facade you have got is just a key hole. On turn of a key it send instruc,on to mul,ple
subsystems and executes a sequence of opera,on and completes the objec,ve. All you know is a key turn which
acts as a facade and simplies your job.


Similarly consider microwave oven, it consists of components like transformer, capacitor, magnetron, waveguide
and some more. To perform an opera,on these dierent components needs to be ac,vated in a sequence. Every
components has dierent outputs and inputs. Imagine you will have separate external controller for all these
components using which you will heat the food. It will be complicated. In this scenario, oven provides you
preprogrammed switches which can be considered as a facade. On click on of a single switch the job gets done.
That single menu switch works as an abstrac,on layer between you and the internal components.

In soTware scenario, you can have interfaces which acts as a facade. Methods in these interfaces contains the
interac,on sequence, formadng and conver,ng data for input for components. As such it will not hold the
business logic.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

Descargar el proyecto FacadeExample.zip disponible en la seccin Recursos/Workspace del si,o del curso.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

UNIDAD 3 ARQUITECTURA DE
TRABAJO
BUSINESS LAYER

Facade Design PaNern

How to code?

UNIDAD 3: ARQUITECTURA DE TRABAJO

Capa del Negocio

Capa DTO
Capa DAO
Capa de u,lidades
Capa de presentacin
Excepciones

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DTO LAYER

Data transfer object (DTO) is a design paSern used to transfer data between soKware applica,on subsystems.
DTOs are oKen used in conjunc,on with data access objects to retrieve data from a database.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DTO LAYER

The dierence between data transfer objects and business objects (BO) or data access objects is that a DTO does

not have any behavior except for storage and retrieval of its own data. DTOs are simple objects that should not
contain any business logic that would require tes,ng


Create a data transfer object (DTO) that holds all data that is required for the remote call. Modify the remote
method signature to accept the DTO as the single parameter and to return a single DTO parameter to the client.
AKer the calling applica,on receives the DTO and stores it as a local object, the applica,on can make a series of

individual procedure calls to the DTO without incurring the overhead of remote calls.


A DTO is a simple container for a set of aggregated data that needs to be transferred across a process or network
boundary. It should contain no business logic and limit its behavior to ac,vi,es such as internal consistency
checking and basic valida,on. Be careful not to make the DTO depend on any new classes as a result of
implemen,ng these methods.

UNIDAD 3: ARQUITECTURA DE TRABAJO

Capa del Negocio

Capa DTO
Capa DAO
Capa de u,lidades
Capa de presentacin
Excepciones

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

The data layer may include the following:

Data Access components

These components abstract the logic required to access the underlying data stores. They centralize common data
access func,onality in order to make the applica,on easier to congure and maintain. Some data access
frameworks may require the developer to iden,fy and implement common data access logic in separate reusable
helper or u,lity data access components. Other data access frameworks, including many Object/Rela,onal

Mapping (O/RM) frameworks, implement such components automa,cally, reducing the amount of data access
code that the developer must write.

Service agents

When a business component must access data provided by an external service, you might need to implement code
to manage the seman,cs of communica,ng with that par,cular service. Service agents implement data access
components that isolate the varying requirements for calling services from your applica,on, and may provide
addi,onal services such as caching, oine support, and basic mapping between the format of the data exposed by
the service and the format your applica,on requires.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

General Design ConsideraKons

Your data access layer must meet the requirements of your applica,on, perform eciently and securely, and be
easy to maintain and extend as business requirements change. When designing the data layer, consider the
following general design guidelines:

Choose an appropriate data access technology. The choice of data access technology depends on the type of data
you must handle, and how you intent to manipulate that data within the applica,on. Certain technologies are

beSer suited to specic scenarios.

Use abstrac4on to implement a loosely coupled interface to the data access layer. This can be accomplished by
dening interface components, such as a gateway with well-known inputs and outputs, which translate requests
into a format understood by components within the layer. In addi,on, you can use interface types or abstract base
classes to dene a shared abstrac,on that must be implemented by interface components.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

General Design ConsideraKons

Encapsulate data access func4onality within the data access layer. The data access layer should hide the details of
data source access. It should be responsible for managing connec,ons, genera,ng queries, and mapping
applica,on en,,es to data source structures. Consumers of the data access layer interact through abstract
interfaces using applica,on en,,es such as custom objects, TypedDataSets, and XML, and should have no
knowledge of the internal details of the data access layer. Separa,ng concerns in this way assists in applica,on
development and maintenance.


Decide how to map applica4on en44es to data source structures. The type of en,ty you use in your applica,on is
the main factor in deciding how to map those en,,es to data source structures. Common design approaches
follow the Domain Model or Table Module paSerns or use Object/Rela,onal Mapping (O/RM) frameworks, though
you may implement business en,,es using dierent formats. You must iden,fy a strategy for popula,ng the
business en,,es or data structures from the data source and making them available to the business layer or
presenta,on layer of the applica,on.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

General Design ConsideraKons

Consider consolida4ng data structures. If you are exposing data through services, consider using Data Transfer
Objects (DTOs) to help you organize the data into unied structures. In addi,on, DTOs encourage coarse-grained
opera,ons while providing a structure that is designed to move data across dierent boundary layers. DTOs can
also span business en,,es for aggregate opera,ons.

Decide how you will manage connec4ons. As a rule, the data access layer should create and manage all connec,ons

to all data sources required by the applica,on. You must choose an appropriate method for storing and protec,ng
connec,on informa,on, perhaps by encryp,ng sec,ons of the congura,on le or limi,ng storage of congura,on
informa,on to the server, in order to conform to corporate security requirements.

Determine how you will handle data excep4ons. The data access layer should catch and (at least ini,ally) handle all
excep,ons associated with data sources and CRUD (Create, Read, Update, and Delete) opera,ons. Excep,ons
concerning the data itself, and data source access and ,meout errors, should be handled in this layer and passed to
other layers only if the failures aect applica,on responsiveness or func,onality.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

General Design ConsideraKons

Consider security risks. The data access layer should protect against aSacks that try to steal or corrupt data, and
protect the mechanisms used to gain access to the data source. For example, sani,ze error and excep,on
informa,on so that data source informa,on is not revealed, and use least privilege accounts to restrict privileges
to only those needed to perform the opera,ons required by the applica,on. Even if the data source itself has the
ability to limit privileges, security should be implemented in the data access layer as well as in the data source.
Database access should be through parameterized queries to prevent SQL injec,on aSacks succeeding. Never use

string concatena,on to build dynamic queries from user input data.

Reduce round trips. Consider batching commands into a single database opera,on.

Consider performance and scalability objec4ves. Scalability and performance objec,ves for the data access layer
should be taken into account during design. For example, when designing an Internet-based commerce
applica,on, data layer performance is likely to be a boSleneck for the applica,on. When data layer performance is
cri,cal, use proling to understand and then reduce or resolve expensive data opera,ons.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

Data Access Object or DAO design paSern is a popular design paSern to implement persistence layer of Java

applica,on.


DAO paSern is based on abstrac,on and encapsula,on design principles and shields rest of applica,on from any
change on persistence layer e.g. change of database from Oracle to MySQL, change of persistence technology e.g.
from File System to Database. For example if you are authen,ca,ng user using rela,onal database and later your
company wants to use LDAP to perform authen,ca,on. If you are using DAO design paSern to access database, it

would be rela,vely safe as you only need to make change on Data Access Layer. DAO design paSern also keeps
coupling low between dierent parts of applica,on.


By using DAO design paSern your View Layer is completely independent to DAO layer and only Service layer has
dependency on it which is also abstracted by using DAO interface. Using DAO paSern to access database is one of
the JDBC best prac,ces to follow.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

What is Data Access Object (DAO) paNern in Java

Data access object design paSern or DAO paSern is way to reduce coupling between Business logic and Persistence
logic. Applica,on business logic oKen needs domain objects which is persisted in either Database, File System or
any other persistence storage.

DAO paSern allows you to encapsulate code for performing CRUD opera,on against persistence from rest of
applica,on. Which means any change on persistence logic will not aect other layers of applica,on which is
already tested. DAO paSern enables applica,on to cope with any change in database provider or persistence
technology.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

Benets of using DAO design paNern

DAO or Data Access Object design paSern is good example of abstrac,on and encapsula,on object oriented
principles. It separates persistence logic in a separate layer called Data access layer which enable applica,on to
react safely on change in Persistence mechanism. For example if you shiK from File based persistence mechanism
to Database, your change will be limited to data access layer and won't impact Service layer or domain Objects.
Data Access Object or DAO paSern is preSy much standard in Java applica,on being it core Java, web applica,on
or enterprise applica,on. Following are couple of more benets of using DAO paSern in Java applica,on:

DAO design paSern allows JUnit test to run faster as it allows to create Mock and avoid connec,ng to database to
run tests. It improves tes,ng because its easy to write test with Mock objects, rather than an Integra,on test with
database. In case of any issues while running Unit test, you only need to check code and not database. Also shields
with database connec,vity and environment issues.


Since DAO paSern is based on interface, it also promotes Object oriented design principle "programming for
interface than implementa,on" which results in exible and quality code.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

IMPLEMENTING FACTORY FOR DATA ACCESS OBJECTS STRATEGY

Using Factory Method PaNern

Consider an example where we are implemen,ng this
strategy in which a DAO factory produces many DAOs
for a single database implementa,on (e.g., Oracle).
The factory produces DAOs such as CustomerDAO,
AccountDAO, OrderDAO, and so forth.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
DAO LAYER

IMPLEMENTING FACTORY FOR DATA ACCESS OBJECTS STRATEGY

Using Abstract Factory PaNern

Consider an example where we are considering
implemen,ng this strategy for three dierent databases.
In this case, the Abstract Factory paSern can be employed.
The sample code shows code excerpt for the abstract

DAOFactory class. This factory produces DAOs such as
CustomerDAO, AccountDAO, OrderDAO, and so forth.
This strategy uses the Factory Method implementa,on
in the factories produced by the Abstract Factory.

The implementa,on for OracleDAOFactory and
SybaseDAOFactory are similar except for specics of
each implementa,on, such as JDBC driver, database URL,
and dierences in SQL syntax, if any.

UNIDAD 3: ARQUITECTURA DE TRABAJO

Capa del Negocio

Capa DTO
Capa DAO
Capa de u,lidades
Capa de presentacin
Excepciones

UNIDAD 3 ARQUITECTURA DE
TRABAJO
PRESENTATION LAYER

UNIDAD 3 ARQUITECTURA DE
TRABAJO
PRESENTATION LAYER

The presenta,on layer contains the components that implement and display the user interface and manage user

interac,on. This layer includes controls for user input and display, in addi,on to components that organize user
interac,on.

The presenta,on layer will usually include the following:

User Interface components


These are the applica,on's visual elements used to display informa,on to the user and accept user input.

PresentaKon Logic components

Presenta,on logic is the applica,on code that denes the logical behavior and structure of the applica,on in a way
that is independent of any specic user interface implementa,on. When implemen,ng the Separated Presenta,on
paSern, the presenta,on logic components may include Presenter, Presenta,on Model, and ViewModel
components. The presenta,on layer may also include Presenta,on Layer Model components that encapsulate the
data from your business layer, or Presenta,on En,ty components that encapsulate business logic and data in a
form that is easily consumable by the presenta,on layer.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
PRESENTATION LAYER

General Design ConsideraKons

There are several key factors that you should consider when designing your presenta,on layer. Use the following
principles to ensure that your design meets the requirements for your applica,on, and follows best prac,ces:

Choose the appropriate applica4on type. The applica,on type you choose will have considerable impact on your
op,ons for the presenta,on layer. Determine if you will implement a rich (smart) client, a Web client, or a rich
Internet applica,on (RIA). Base your decision on applica,on requirements, and on organiza,onal and

infrastructure constraints.

Choose the appropriate UI technology. Dierent applica,on types provide dierent sets of technologies that you
can use to develop the presenta,on layer. Each technology type has dis,nct advantages that can aect your ability
to create a suitable presenta,on layer design.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
PRESENTATION LAYER

General Design ConsideraKons

Use the relevant paBerns. Review the presenta,on layer paSerns for proven solu,ons to common presenta,on
problems. Keep in mind that not all paSerns apply equally to all archetypes. However, the general paSern of
Separated Presenta,on, which separates presenta,on specic concerns from the underlying applica,on logic,
applies to all applica,on types. Specic paSerns such as MVC, MVP, and Supervising Presenter are commonly used
in presenta,on layer design of rich client applica,ons and RIAs. Variants of the Model-View-Controller (MVC) and
Model-View-Presenter (MVP) paSerns can be used in Web applica,ons.


Design for separa4on of concerns. Use dedicated UI components that focus on rendering, display, and user
interac,on. Consider using dedicated presenta,on logic components to manage the processing of user interac,on
where this is complex or where you want to be able to unit test it. Also, consider using dedicated presenta,on
en,,es to represent your business logic and data in a form that is easily consumable by your UI and presenta,on
logic components. Presenta,on en,,es encapsulate within the presenta,on layer the business logic and data from
your business layer, for use in much the same way as business en,,es are used in the business layer.

UNIDAD 3 ARQUITECTURA DE
TRABAJO
PRESENTATION LAYER

General Design ConsideraKons

Consider human interface guidelines. Implement your organiza,on's guidelines for UI design, including factors such
as accessibility, localiza,on, and usability when designing the presenta,on layer. Review established UI guidelines
for interac,vity, usability, system compa,bility, conformance, and relevant UI design paSerns based on the client
type and the technologies that you choose, and apply those applicable to your applica,on design and
requirements.


Adhere to user driven design principles. Before designing your presenta,on layer, understand your customer. Use
surveys, usability studies, and interviews to determine the best presenta,on design to meet your customer's
requirements.

Gracias por su atencin

Boris Prez
borisperezg@ufps.edu.co