1 / 35

Implementando a Arquitetura de Referência OpenEdge (OERA) - Parte I

Implementando a Arquitetura de Referência OpenEdge (OERA) - Parte I. Alessandro Martins Technical Architect Field Services Latin America Operations. Agenda. Introduzindo a implementação de referência Business Entities e Data Access Objects Pontos de discussão sobre Lógica de Negócio

darice
Download Presentation

Implementando a Arquitetura de Referência OpenEdge (OERA) - Parte I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementando a Arquitetura de Referência OpenEdge (OERA) - Parte I Alessandro Martins Technical Architect Field Services Latin America Operations

  2. Agenda • Introduzindo a implementação de referência • Business Entities e Data Access Objects • Pontos de discussão sobre Lógica de Negócio • Conclusões

  3. Moderna Arquitetura de Aplicações Lógica de negócio comum com modelos avançados Acesso a dados abstraído do repositório OpenEdge Reference Architecture – uma visão em camadas Usuários Serviços Corporativos Camadas de apresentação e integração separadas Camada de Apresentação Camada de Integração Camada de Serviços de Negócio Camada de Acesso a Dados Repositório de Dados Não-gerenciado Repositório de Dados Gerenciado

  4. Quais são os objetivos da Implementação de Referência? • Prover um entendimento da OpenEdge Reference Architecture pela descrição de uma implementação de exemplo • Auxiliar na compreensão das melhores práticas no uso dos recursos do OpenEdge • Motivar arquitetos e desenvolvedores a pensar em aplicar a Arquitetura em seus próprios projetos

  5. O que não são objetivos? • Não se trata de um novo framework • Não pretende ser abrangente ou cobrir todos os casos possíveis para a aplicação • Não possui a intenção de ser comercializado • Não possui a intenção de ser utilizado sem mudanças, extensões ou estudo

  6. Como devo usar a Implementação de Referência? • Use-a para aprender os conceitos da Arquitetura mais profundamente • Use-a para aprender como melhor utilizar os constructos do Progress 4GL e outros recursos • Considere-a como um pontode partida potencialmente útil no desenvolvimento de aplicações sobre OpenEdge 10

  7. Que recursos estão disponíveis?- Artigos e Códigos de Exemplo 1. Introduction 2. Business Entities and Data Access Objects 3. The Service Interface Layer 4. Using Advanced ProDataSet Language Features 5. Using an Unmanaged Data Store 6. Building a .NET™ Interface to Business Entities 7. Advanced Business Logic Issues 8. Context Management 9. Building a WebSpeed® User Interface 10. …

  8. O que há na base de código da Implementação de Referência? • Diretório Templates • Procedures de modelo para BE’s, DAO’s etc. • Diretório Support • Super-procedures e procedures em geral para apoio • Diretório Samples • Exemplos dos códigos presentes nos artigos • Usam a base sports2000 mas não há nada específico sobre bases de dados em qualquer código

  9. Onde eu encontro tudo isto? • Os artigos e o código de exemplo estão no site do PSDN: • psdn.progress.com/library/product_info/ oera/index.ssp • Há atualizações em andamento • Material em vias de lançamento descreverá as melhores práticas para se usarOpenEdge 10.1 e seus recursos OO4GL

  10. Agenda • Introduzindo a implementação de referência • Business Entities e Data Access Objects • Pontos de discussão sobre Lógica de Negócio • Conclusões

  11. O Business Entity e o Data Access Object na Arquitetura Usuários Serviços Corporativos Camada de Apresentação Camada de Integração Business Entity Camada de Serviços de Negócio Data Access Object Camada de Acesso a Dados Repositório de Dados Gerenciado Repositório de Dados Não-gerenciado

  12. Business Entity • Gerencia a visão lógica, interna dos dados da aplicação • Fornece dados para a interface com o usuário e outras camadas de integração • Contém lógica de negócio • Dados são melhor representados como ProDataSets e suas temp-tables • O Business Entity é o valor central da construção de aplicações em OpenEdge BB Business Entity Data Access Object IU API API lógico físico

  13. Data Access Object • Gerencia o repositório de dados físico • Entende o esquema e outras descrições dos dados físicos • Mapeia entre a visão física e a visão lógica • Todas as referências a dados físicos devem estar confinados ao Data Access Object BD Business Entity Data Access Object IU API API lógico físico

  14. O ProDataSet como um Bloco de Construção Data-Source1 Base de Dados Field MapCustNum Name Contact Query…Q1 for Customer CustomerTT OrderTT Data-Source2 6 1 01/05/9336 1 01/19/9379 1 02/10/93 1 Lift Line Skiing 2 Urpon Frisbee 3 Hoops Croquet Field MapOrderNum CustNum OrderDate Query… Q2 for Order Order Event Logic Customer 1 53 01/01/93 2 81 01/04/93 3 66 01/04/93 Lift Line Skiing Urpon Frisbee Hoops Croquet Dataset:Before-fillBuffer:Before-fillBefore-row-fill Row-Add Row-Delete… ProDataSet Data-Relation1

  15. Construindo os Objetos –Definição das Temp-tables • Definir temp-tables para as definições lógicas dos dados • Cada temp-table em seu próprio arquivo de include DEFINE TEMP-TABLE eOrder FIELD OrderNum… etOrder.i DEFINE TEMP-TABLE eOrderLine FIELD OrderNum… FIELD LineNum… etOrderLine.i • Separar definições físicas das lógicas

  16. Prefixo do nome da tabela: e Por exemplo: eCustomer Prefixo do nome do arquivo de include: et etCustomer.i Renomear campos para consistência ou melhorar compreensão Remover elementos: Campos Índices Adicionar outros campos provenientes de Joins Adicionar campos calculados que possam ser requeridos por facilidade de uso Adicionar BEFORE-TABLE ao final da definição no caso de se fazer alterações Não usar a sintaxe LIKE Temp-table LIKE database-table Field LIKE database-field Linhas mestras para Definições das Temp-table

  17. TEMP-DB Maintenance Tool (10.0B)

  18. Construindo os Objetos – Data-Source Objects Base de Dados da Aplicação • Construir as procedures correspondentes aos objetos de Data-Source • Cada objeto mapeia uma temp-table ao dado físico correspondente. DEFINE DATA-SOURCE srcOrder FOR QUERY qOrder. ATTACH-DATA-SOURCE() sceOrder.p etOrder.i DEFINE DATA-SOURCE srcOrderLine FOR BUFFER OrderLine. ATTACH-DATA-SOURCE() sceOrderLine.p etOrderLine.i

  19. Construindo os Objetos –Definições dos ProDataSets • Definir ProDataSets para conjuntos de dados relacionados • Cada ProDataSet é a base para um Business Entity DEFINE DATASET dsOrder FOR eOrder, eOrderline… dsOrder.i etOrder.i etOrderLine.i

  20. Construindo os Objetos – Data Access Object • Construir os Data Access Objects para o ProDataSet • Gerencia todos os Data-Source Objects daOrder.p sceOrder.p dsOrder.i sceOrderLine.p

  21. Todos os componentes de acesso a dados juntos sceOrder.p DEF DATA-SOURCE ATTACH-DATA-SOURCE RowFill handler sceOrderLine.p DEF DATA-SOURCE ATTACH-DATA-SOURCE sceItem.p DEF DATA-SOURCE ATTACH-DATA-SOURCE daSupport.p initDataSources: daOrder.p {dsOrder.i} {daEntity.i} SUPER Base de Dados da Aplicação SUPER daOrderValidate.p (opcional) eOrderLineModifyBeginTrans: SUPER

  22. Construindo os Objetos –Business Entities • Construir um Business Entity para cada ProDataSet • Lida com a lógica de negócio sobre os dados lógicos. • Define a API para acesso a partir de outros objetos. DEFINE DATASET dsOrder FOR eOrder, eOrderline… BusinessLogic: END PROCEDURE. dsOrder.i etOrder.i etOrderLine.i

  23. Componenets Business Entity Juntos dsOrder.i {etOrder.i} {etOrderLine.i} {etItem.i} DEFINE DATASET… beOrder.p {dsOrder.i} {beEntity.i} beSupport.p fetchCustom saveChanges beEntity.i RUN daOrder.p SUPER beOrderValidate.p (optional) eOrderLineModifyPreTrans: SUPER Data Access Object

  24. Agenda • Introduzindo a implementação de referência • Business Entities e Data Access Objects • Pontos de discussão sobre Lógica de Negócio • Conclusões

  25. Pontos de discussão sobre lógica dos Business Entities • Quão estritamente devo aderir à separação de lógicas? • Devo usar uma chamada de API apenas para um CAN-FIND? • Devo deferir isto a uma trigger de base de dados? • Quanto do comportamento padrão deve ser automatizado por “mágica”? • Como eu ajusto a lógica para permitir reuso de tabelas por parte de outros ProDataSets? • Qunado eu devo usar referências a temp-tables ou ProDataSets estáticas ou dinâmicas?

  26. Acessando outras Entities através de suas APIs • Evitar acesso direto à base de dados para outras tabelas a partir de seus Business Entities FIND eOrder WHERE eOrder.OrderNum = eOrderLine.OrderNum {&NoError}. hCustomer = SIfindRow("Customer", "eCustomer", "CustNum", STRING(eOrder.CustNum)) . IF hCustomer:BUFFER-FIELD("Discount"):BUFFER-VALUE < .35 THEN DO: ASSIGN BUFFER eOrderLine:ERROR = YES BUFFER eOrderLine:ERROR-STRING = "Line " + STRING(eOrderLine.LineNum) + ": Changes not allowed … ". RETURN. END.

  27. Comportamento “Mágico” Padrão • Procedures de callback chamadas através de uma convenção de nomenclatura PROCEDURE initDataSources : IF LOOKUP(phDataSet:NAME + "BeforeFill", cEntries) NE 0 THEN phDataSet:SET-CALLBACK-PROCEDURE ("BEFORE-FILL", phDataSet:NAME + "BeforeFill", TARGET-PROCEDURE). IF LOOKUP(phDataSet:NAME + "AfterFill", cEntries) NE 0 THEN phDataSet:SET-CALLBACK-PROCEDURE ("AFTER-FILL", phDataSet:NAME + "AfterFill", TARGET-PROCEDURE).

  28. Organizando a Lógica para Máximo Reuso • Lógica que referencia mais de uma tabela no ProDataSet • Deveria ser colocada dentro do próprio Data Access Object PROCEDURE eOrderLineAfterFill: DEFINE INPUT PARAMETER DATASET FOR dsOrder. DEFINE VARIABLE dTotal AS DECIMAL NO-UNDO. FOR EACH OrderLine WHERE OrderLine.OrderNum = eOrder.OrderNum: dTotal = dTotal + OrderLine.ExtendedPrice. END. eOrder.OrderTotal = dTotal. END PROCEDURE.

  29. Código Estático X Código Dinâmico • Referências dinâmicas às temp-tables permitem reutilização PROCEDURE eItemAfterRowFill: DEFINE INPUT PARAMETER DATASET-HANDLE phDataSet. …. hItemName =phDataSet:GET-BUFFER-HANDLE("eItem"):BUFFER-FIELD("ItemName"). DO iType = 1 TO NUM-ENTRIES(cItemTypes): cType = ENTRY(iType, cItemTypes). IF INDEX(hItemName:STRING-VALUE, cType) NE 0 THEN hItemName:BUFFER-VALUE = REPLACE(hItemName:BUFFER-VALUE, cType, cType). END. END PROCEDURE.

  30. Agenda • Introduzindo a implementação de referência • Business Entities e Data Access Objects • Pontos de discussão sobre Lógica de Negócio • Conclusões

  31. Resumindo... • Examinar os materiais da implementação-exemplo como base para aprendizado e discussão • Utilizar as partes úteis • Estender ou substituir parter para seus própositos • Deve-se esperar que continue crescendo e mudando • Não se deve esperar que seja completamente (ou mesmo formalmente) suportado

  32. Perguntas?

  33. Grato pelo seu tempo!

More Related