Na sequência deste post no blogue sobre o novo conceito de selecção de entidades partilháveis e as discussões subsequentes no fórum, vamos agora ter tempo para explicar como a ORDA se enquadra no futuro.
Há vários meses atrás, introduzimos orgulhosamente a ORDA e todos os seus novos conceitos.
Aprendeu que na ORDA, TUDO é um objecto:
- a base de dados em si é um objecto (o objecto datastore)
- cada tabela é um objecto de dataclass
- cada registo pode ser um objecto de entidade
- uma selecção actual pode ser um objecto de selecção de entidade
Além disso, os dias em que estava preso com uma única selecção de corrente por mesa, acabaram. Pode gerir tantas selecções de entidades quantas quiser. E como tudo é um objecto, está pronto para um código mais fácil de manusear, codificação genérica, e serialização para comunicar com outro software.
Sabia que tudo isto sai da caixa com 4D? Não há pilha de tecnologia para lidar e não há dores de cabeça com uma estrutura complexa.
4D v17 também incluiu outra opção muito importante: partilhar dados entre processos com objectos e colecções partilhados. É agora muito fácil partilhar vários dados entre processos preventivos.
4D está confiantemente a conduzi-lo para um mundo de multi-tarefas, tirando grande partido das capacidades do processador para melhorar o desempenho nas suas aplicações.
O melhor desempenho e a codificação mais fácil dependem desta equação: objectos + partilha.
E depois vem o conceito de selecção de entidades partilháveis
vamos estudar um caso de primeira utilização
Talvez já tenha descoberto todas as vantagens do TRABALHADOR para executar tarefas em modo preventivo. Até agora apenas, objectos partilhados e colecções partilhadas poderiam ser-lhe transmitidos como referência.
Imagine os benefícios que poderia colher ao passar selecções de entidades como referência, também … tal como qualquer item partilhado.
Aqui está um caso de uso apropriado:
1- Identificar facturas pagas e facturas não pagas
2- Enviar emails de reconhecimento aos clientes pelas suas facturas pagas e emails de lembrete pelas suas facturas não pagas. Como esta tarefa é potencialmente demorada, queremos delegá-la a um TRABALHADOR em modo assíncrono.
O código poderia ter este aspecto:
var $paid; $unpaid: cs.InvoicesSelection
//Get entity selections for paid and unpaid invoices
$paid :=ds.Invoices.query("status=:1"; "Paid")
$unpaid :=ds.Invoices.query("status=:1"; "Unpaid")
//Pass entity selections as references to the WORKER
CALL WORKER ("mailing"; "sendMails"; $paid; $unpaid)
O método sendMails acederá à selecção da entidade aprovada como referência. O código completo foi fornecido neste post do blogue.
Reparou em alguma coisa? As selecções da entidade são passadas “tal como estão” ao trabalhador. Estão prontas para serem partilhadas.
O próximo passo: novas sessões web
O passo seguinte é melhorar as suas aplicações web com uma poderosa gestão de sessões concebida para a escalabilidade.
Numa versão futura, as sessões web 4D serão capazes de tratar vários processos(ou seja, pedidos) do mesmo agente do utilizador, ao mesmo tempo. Isto não só melhorará o desempenho, como também proporcionará o grande benefício da partilha de informação entre processos.
E isto não é tudo! Será capaz de gerir autenticação personalizada atribuindo informações à sua sessão web.
vamos discutir um caso de utilização
Imagine uma empresa global(Acme Corp.) a vender computadores em todo o mundo a vários clientes (empresas, pessoas, escolas, etc.) através de uma aplicação de CRM.
Cada vendedor gere a sua própria carteira de clientes. Estão ligados à aplicação durante todo o dia para fazer e registar negócios na sua carteira de clientes.
Podemos presumir que a base de dados contém pelo menos 2 dataclasses ligados: Clientes e VendedoresPerson (um vendedor tem vários clientes).
Na figura abaixo, podemos ver isso:
- Os 10 principais clientesda Acme Corp. são armazenados em Armazenamento, sendo assim partilhados entre todos os processos em curso na aplicação
- Cada vendedor tem a sua própria sessão com os seus 10 principais clientes guardada na mesma
- Os vendedores podem navegar por cada página da aplicação e ter os seus 10 principais clientes expostos, bem como os 10 principais clientes da Acme Corp.
Estes “top 10” são selecções de entidades do Cliente partilhadas quer no Armazenamento quer na sessão do utilizador.
Torna-se então muito fácil desenvolver formas de o fazer:
- testar se um vendedor é um bom executante(ou seja, existe uma intersecção entre os seus 10 principais clientes e os 10 principais clientes da Acme Corp?)
- refrescar os 10 principais clientes do vendedor
- etc.
mais concretamente em código 4D
Os 10 principais clientesda Acme Corp. são as entidades de Clientes colocadas em Armazenamento, pelo menos no arranque da base de dados:
Use (Storage)
Storage .acmeCorpTop10:=ds.Customers.all().orderBy("totalPurchase desc").slice(0; 10)
End use
A sessão web não é mais do que … um objecto: o objecto da Sessão. Este objecto contém um objecto partilhado (atributostorage ) para que todos os pedidos tratados pela sessão possam partilhar dados.
Quando o vendedor se autentica, é muito fácil armazenar os seus 10 principais clientes com algum código do género:
// $salesID is the salesperson's ID
// Get the salesperson's top 10 customers
$top10:=ds.Customers.query("salesPerson.salesID = :1"; $salesID).orderBy("totalPurchase desc").slice(0; 10)
// Put $top10 in the session
Use (Session.storage)
Session .storage.myTop10. :=$userTop10
End use
Nota: O exemplo de código acima é uma pré-visualização de uma futura versão de 4D.
Depois, todos os processos(ou seja, pedidos) provenientes do agente do utilizador podem aceder a estes 10 principais clientes.
Note que coloca as selecções da entidade “tal como está” em Storage e na sessão. Não há necessidade de as copiar como partilháveis!
Isto é possível porque as selecções de entidades são partilháveis por defeito.
em conclusão
Optamos por dar uma vantagem a todos os casos de utilização futura relacionados com a escalabilidade e desempenho, que deverão ser as principais questões das suas futuras aplicações. Um utilizador final feliz é aquele que obtém o resultado certo no mais curto espaço de tempo.
Esteja ciente de que o objectivo de uma selecção de entidade partilhável deve ser tratado como referência. É mais leve na memória.
Além disso, algumas optimizações transparentes são tratadas por 4D para si quando utiliza selecções de entidades partilháveis: enquanto copia selecções de entidades, se pedir um resultado partilhável, sempre que aplicável, 4D não faz uma cópia das selecções de entidades, mas devolve a mesma referência.
Graças a tudo isto, evita copiar as suas selecções de entidades como partilhadas cada vez que as quer partilhar. Pensamos que estes tempos serão demasiado abundantes à medida que nos dirigimos cada vez mais para a execução de código em modo preventivo, graças ao progresso contínuo dos processadores de múltiplos núcleos.