Main Module

O módulo de dados principal contém vários objetos associados a uma sessão:

• A conexão com o banco de dados (TFDConnection)

• Tabelas ou consultas para acessar o banco de dados (TFDTable, TFDQuery)

• Fontes de dados para acessar os objetos do banco de dados a partir de controles vinculados a dados

• Uma lista de ações (TActionList)

• Uma lista de imagens (TUniNativeImageList) com um adaptador (TUniImageListAdapter) para usar as imagens da lista de ações

Usando os componentes anteriores e seu código interno, o MainModule encapsula a maior parte da lógica de negócio desta aplicação simples.

Criar / Destruir

Cada sessão tem sua própria conexão com o banco de dados. a string de conexão já está disponível no módulo do servidor.

procedure TUniMainModule.UniGUIMainModuleCreate(Sender: TObject);
begin
  Conn.ConnectionString := UniServerModule.ConnString;
  Conn.Open;
end;

procedure TUniMainModule.UniGUIMainModuleDestroy(Sender: TObject);
begin
  Conn.Close;
end;

Processo de login

Dependendo de como o usuário acessa a aplicação, a aplicação irá instanciar o formulário de login para desktop ou para touch. Após digitar o nome de usuário e a senha, pressionar OK acionará o processo de validação do login.

{ Validação de login e seleção da plataforma da sessão }

function TUniMainModule.Login(
  aUsername,
  aPassword: string;
  aDesktop : boolean
): boolean;
var
  UserFound : boolean;
  IsAdmin   : Variant;
begin
  Result := false;

  IsAdmin :=
    Conn.ExecSQLScalar(
      Format(
        'SELECT Admin FROM Users WHERE Username = ''%s'' AND Password = ''%s''',
        [aUserName, aPassword]
      )
    );

  UserFound := not VarIsClear(IsAdmin);

  if UserFound then
  begin
    FUsername := aUsername;
    FPassword := aPassword;
    FIsAdmin := not VarIsNull(IsAdmin) and IsAdmin;
    actEditUsers.Visible := FIsAdmin;

    if aDesktop then
      SetAsDesktop
    else
      SetAsMobile;

    Result := true;
  end;
end;

Login encapsula duas regras de negócio: como identificar um usuário válido (combinação usuário/senha) e que tipo de usuário pode ver a ação "Edit Users".

Seleção de plataforma

Cada formulário de login (dLoginForm e mLoginForm) informa ao MainModule a plataforma selecionada ao tentar um login.

{ Seleção de plataforma }

procedure TUniMainModule.SetAsDesktop;
begin
  FServices := TdServices.Create;
end;

procedure TUniMainModule.SetAsMobile;
begin
  FServices := TmServices.Create;
end;

Após selecionar uma plataforma, a sessão saberá como interagir com o usuário nessa plataforma. A solução usada nesta aplicação é agrupar diferentes implementações de ações comuns por trás de uma fachada/interface e instanciar a correta para a plataforma selecionada.

A interface é IService:

unit Services;

interface

type
  IServices = interface
    ['{CB442F06-D33F-488B-B643-22887D8F499B}']
    procedure EditUsers;
    procedure EditOrders;
    procedure ReportSales(const aPDFUrl : string);
  end;

implementation

end.

Existem duas implementações (para desktop e touch, respectivamente).

Desktop

unit dServices;

interface

uses
  Classes,
  Services;

type
  TdServices = class(TInterfacedObject, IServices)
    procedure EditUsers;
    procedure EditOrders;
    procedure ReportSales(const aPDFUrl : string);
  end;

implementation

uses
  Vcl.Controls,
  uniGUIForm,
  _dUsersForm,
  _dOrdersForm,
  _dSalesReportForm;

{ TdServices }

procedure TdServices.EditUsers;
begin
  dUsersForm.ShowModal();
end;

procedure TdServices.EditOrders;
begin
  dOrdersForm.ShowModal();
end;

procedure TdServices.ReportSales(const aPDFUrl : string);
var
  frm : TdSalesReportForm;
begin
  frm := dSalesReportForm;
  frm.PDFUrl := aPDFUrl;
  frm.ShowModal();
end;

end.

Touch

unit mServices;

interface

uses
  Classes,
  Services;

type
  TmServices = class(TInterfacedObject, IServices)
    procedure EditUsers;
    procedure EditOrders;
    procedure ReportSales(const aPDFUrl : string);
  end;

implementation

uses
  Vcl.Controls,
  uniGUImForm,
  _mUsersForm,
  _mOrdersForm,
  _mSalesReportForm;

{ TdServices }

procedure TmServices.EditUsers;
begin
  mUsersForm.ShowModal();
end;

procedure TmServices.EditOrders;
begin
  mOrdersForm.ShowModal();
end;

procedure TmServices.ReportSales(const aPDFUrl : string);
var
  frm : TmSalesReportForm;
begin
  frm := mSalesReportForm;
  frm.PDFUrl := aPDFUrl;
  frm.ShowModal();
end;

end.

Fica agora claro que ambas implementações são praticamente idênticas, porque as únicas diferenças são as classes que implementam cada método na interface. Isso é uma limitação significativa nesta solução, pois há código duplicado, o que é uma má prática de programação. Uma das possíveis soluções é usar Dependency Injection para localizar as classes corretas para uma dada plataforma e evitar duplicação de código.

Implementando a tela de lançamento com ações

Uma das melhores práticas para separar a interface do usuário da lógica de negócio é usar ações. O módulo de dados principal tem uma lista de ações com as seguintes ações:

• Edit Users (disponível somente para administradores)

• Edit Orders

• Relatório de Vendas

Não importa que tipo de controle visual seja usado pela plataforma alvo, se ele suporta ações, poderá acionar as ações selecionadas. Por exemplo, o formulário principal desktop expõe essas ações em um TUniMainMenu e em uma TUniToolBar, enquanto o formulário principal touch as expõe em botões grandes.

A interface do usuário não está solicitando explicitamente nada ao MainModule e o MainModule não tem conhecimento da interface do usuário de forma alguma.

Por outro lado, a lógica de negócio requer a execução das ações solicitadas, que é o motivo de criar a interface Services.

{ Ações de lógica de negócio da tela de lançamento }

procedure TUniMainModule.actEditOrdersExecute(Sender: TObject);
begin
  Services.EditOrders;
end;

procedure TUniMainModule.actEditUsersExecute(Sender: TObject);
begin
  Services.EditUsers;
end;

procedure TUniMainModule.actReportSalesExecute(Sender: TObject);
var
  PDFUrl : string;
begin
  PDFUrl := ExportSalesReportToPDF;
  if PDFUrl <> '' then
    Services.ReportSales(PDFUrl);
end;

function TUniMainModule.ExportSalesReportToPDF : string;
var
  dm : TfrDataModule;
begin
  dm := TfrDataModule.Create(nil);
  try
    Result := dm.ExportReport;
  finally
    dm.Free;
  end;
end;

procedure TUniMainModule.UniGUIMainModuleNewComponent(AComponent: TComponent);
begin
  if AComponent is TfrxReport then
    (AComponent as TfrxReport).EngineOptions.UseGlobalDataSetList := False;
end;

Seguindo as melhores práticas, somente ao solicitar um relatório o módulo de dados correspondente é criado e usado para exportar o relatório em formato PDF.

Movendo a lógica de negócio da interface do usuário para o módulo de dados

Requisições explícitas do usuário já foram mapeadas para ações e tratadas no módulo de dados. Outras solicitações do usuário chegam ao módulo de dados como eventos relacionados a dados que devem ser tratados de acordo com a lógica de negócio da aplicação. Mas existe uma lógica de negócio implícita que precisa de uma solicitação explícita: abrir e fechar conjuntos de dados usados por formulários concretos.

Nesta aplicação não usaremos nenhum sistema de registro (que poderia relacionar formulários concretos ou interfaces a recursos), apenas chamadas explícitas solicitando suporte do módulo de dados.

Gerenciamento de recursos

{ Gerenciamento de recursos para formulários }

procedure TUniMainModule.OnCreateOrdersEditor(Sender: TObject);
begin
  tblCustomers.Open;
  tblProducts.Open;
  tblOrders.Open;
  tblItems.Open;
end;

procedure TUniMainModule.OnDestroyOrdersEditor(Sender: TObject);
begin
  tblItems.Close;
  tblOrders.Close;
  tblProducts.Close;
  tblCustomers.Close;
end;

procedure TUniMainModule.OnCreateUsersEditor(Sender: TObject);
begin
  tblUsers.Open;
end;

procedure TUniMainModule.OnDestroyUsersEditor(Sender: TObject);
begin
  tblUsers.Close;
end;

Cada formulário que requer recursos do módulo de dados chamará UniMainModule.OnCreate

(Self) e OnDestroy(Self) para que o módulo de dados configure e libere quaisquer recursos necessários. No código anterior o módulo de dados abre e fecha os conjuntos de dados requeridos por cada formulário.

Esse código em particular é apenas lógica de negócio do lado do servidor, e poderia ser ativado usando Dependency Injection. Isso pode ser feito registrando recursos com seus respectivos métodos OnCreate e OnDestroy.

Em situações mais complicadas, poderia ser possível "injetar" componentes no formulário concreto. Por exemplo, o MainMenu da aplicação poderia ser definido no módulo de dados, e algum método genérico poderia ser capaz de criar o equivalente correto para o formulário Sender com base em seu tipo.

O objetivo desse tipo de programação é alcançar maior desacoplamento entre a interface do usuário e a lógica de negócio. Os resultados virão mais tarde ao analisar a implementação de cada formulário.

Tratamento de eventos relacionados a dados

A maior parte da lógica de negócio pertence a esta categoria. É típico validar mudanças em OnBeforePost, atualizar informações ou acionar outras ações em OnAfterPost, calcular campos virtuais em OnCalcFields, etc.

{ Manipuladores de eventos de acesso a dados }

procedure TUniMainModule.tblItemsAfterPost(DataSet: TDataSet);
begin
  // Após gravar uma alteração em items, forçar um recálculo do pedido
  tblOrders.Edit;
  tblOrdersCalcFields(tblOrders);
  tblOrders.Post;
end;

procedure TUniMainModule.tblItemsCalcFields(DataSet: TDataSet);
begin
  if Conn.Connected andnot tblItemsQuantity.IsNull andnot tblItemsPrice.IsNull then
    tblItemsTotal.Value := tblItemsQuantity.Value * tblItemsPrice.Value;
end;

procedure TUniMainModule.tblOrdersCalcFields(DataSet: TDataSet);
var
  t : Variant;
begin
  t :=
    Conn.ExecSQLScalar(
      Format(
        'SELECT' +
        '  sum(i.Quantity * p.Price) ' +
        'FROM' +
        '  Orders o' +
        '    INNER JOIN Items    i ON o.ID = i.OrderID' +
        '    INNER JOIN Products p ON i.ProductID = p.ID ' +
        'WHERE o.ID = %d',
        [tblOrdersID.Value]
      )
    );

  if VarIsNull(t) then
    t := 0;

  tblOrdersTotal.Value := t;
end;

Executando ações

Algumas ações não são padrão para um controle relacionado a dados e são expostas em botões, itens de menu, etc.

{ Ações de lógica de negócio }

procedure TUniMainModule.actMarkAsPaidExecute(Sender: TObject);
begin
  if tblOrders.State = dsBrowse then
    tblOrders.Edit;
  tblOrdersPaid.Value := Now;
  tblOrders.Post;
end;

procedure TUniMainModule.actToggleAdminExecute(Sender: TObject);
var
  AdminQty : integer;
begin
  if tblUsers.State <> dsBrowse then
    ShowMessage('Commit any pending udpate before requesting admin status changes!')
  else
  begin
    AdminQty := Conn.ExecSQLScalar('SELECT count(*) FROM Users WHERE Admin = 1');

    if tblUsersAdmin.Value and (AdminQty = 1) then
      ShowMessage('You need at least one admin account!')
    else
    begin
      tblUsers.Edit;
      tblUsersAdmin.Value := tblUsersAdmin.IsNull or not tblUsersAdmin.Value;
      tblUsers.Post;
    end;
  end;
end;

A última ação levanta uma preocupação. Se a lógica de negócio determina que pelo menos um usuário deve ser admin, por que essa validação só acontece quando o usuário pressiona o botão "Toggle Admin Status"? O que acontecerá se a mesma ação ocorrer clicando na checkbox Admin na interface do usuário?

Existem duas opções para resolver o problema anterior: tornar a coluna Admin somente leitura, ou executar essa validação em ambos os lugares (aqui e em tblUsers.OnBeforePost).