POO II - Unidad 3

PROGRAMACION ORIENTADA A OBJETOS II CÓD. 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 presentación •  Excepciones

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 flow through an applica,on. Visualizing the applica,on’s 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.


INTRODUCTION Layer IsolaKon Isola,ng problem domains, such as persistence, web naviga,on, and user interface, into separate layers creates a flexible and testable applica,on. Implementa,ons of each layer will vary independently, increasing the flexibility 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 different 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 benefits 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 flexible and testable


AOP – Aspect Oriented Programming

INTRODUCTION Layer IsolaKon


BUSINESS LAYER


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 •  Workflows 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. •  Specific 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 specific communica,on protocol for talking to the credit card network


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).


BUSINESS LAYER Facade Design PaNern The facade paSern is a Gang of Four design paSern. This is a structural paSern as it defines a manner for crea,ng rela,onships between classes or en,,es. The facade design paSern is used to define a simplified interface to a more complex subsystem. GoF defini,on for facade design paSern is, “Provide a unified interface to a set of interfaces in a subsystem. Facade PaSern defines a higher-‐level interface that makes the subsystem easier to use.” How do we infer the above defini,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 flow we may have to interact with mul,ple interfaces. To simplify that interac,on process, we introduce facade layer. Facade exposes a simplified 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.


BUSINESS LAYER Facade Design PaNern


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.


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 simplifies your job. Similarly consider microwave oven, it consists of components like transformer, capacitor, magnetron, waveguide and some more. To perform an opera,on these different components needs to be ac,vated in a sequence. Every components has different 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.


BUSINESS LAYER Facade Design PaNern Descargar el proyecto FacadeExample.zip disponible en la sección Recursos/Workspace del si,o del curso.




How to code?

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.


DTO LAYER The difference 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.


DAO LAYER


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 configure 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, offline support, and basic mapping between the format of the data exposed by the service and the format your applica,on requires.


DAO LAYER General Design ConsideraKons Your data access layer must meet the requirements of your applica,on, perform efficiently 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 specific scenarios. Use abstrac4on to implement a loosely coupled interface to the data access layer. This can be accomplished by defining 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 define a shared abstrac,on that must be implemented by interface components.


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 different 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.


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 unified structures. In addi,on, DTOs encourage coarse-‐grained opera,ons while providing a structure that is designed to move data across different 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 configura,on file or limi,ng storage of configura,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 affect applica,on responsiveness or func,onality.


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 profiling to understand and then reduce or resolve expensive data opera,ons.


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 different 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.


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 affect 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.


DAO LAYER Benefits 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 benefits 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 flexible and quality code.


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.


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 different 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 specifics of each implementa,on, such as JDBC driver, database URL, and differences in SQL syntax, if any.


PRESENTATION LAYER


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 defines the logical behavior and structure of the applica,on in a way that is independent of any specific 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.


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. Different applica,on types provide different sets of technologies that you can use to develop the presenta,on layer. Each technology type has dis,nct advantages that can affect your ability to create a suitable presenta,on layer design.


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 specific concerns from the underlying applica,on logic, applies to all applica,on types. Specific 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.


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 atención

[email protected]

Boris Pérez

POO II - Unidad 3

Documents

Transcript of POO II - Unidad 3