¶ 0. Estrutura
¶ 0.1 Pastas do Sistema
SSAG.Core/
├── UI/ # Camada de Interface do Usuário
│ ├── Components/ # Componentes reutilizáveis de UI
│ ├── Pages/ # Páginas principais da aplicação
│ ├── Layouts/ # Layouts globais da aplicação
│ ├── Styles/ # Arquivos CSS ou SCSS (se aplicável)
│ ├── Shared/ # Recursos compartilhados entre componentes
│ ├── Scripts/ # Scripts JavaScript (se aplicável)
│ └── wwwroot/ # Arquivos estáticos (imagens, JS, CSS)
│
├── Application/ # Camada de aplicação
│ ├── DTOs/ # Objetos de Transferência de Dados
│ ├── Interfaces/ # Interfaces para serviços e handlers
│ ├── Services/ # Serviços de aplicação
│ └── UseCases/ # Casos de uso
│
├── Domain/ # Camada de domínio
│ ├── Aggregates/ # Agregados do sistema
│ ├── Entities/ # Entidades principais
│ ├── ValueObjects/ # Objetos de Valor
│ ├── Repositories/ # Interfaces de repositórios
│ ├── Services/ # Serviços de domínio
│ ├── Events/ # Eventos do domínio
│ └── Specifications/ # Especificações
│
├── Infrastructure/ # Camada de infraestrutura
│ ├── Persistence/ # Persistência
│ │ ├── Repositories/ # Implementações de repositórios
│ │ ├── EFCore/ # Implementação para Entity Framework
│ │ ├── SqlServer/ # Implementação para Sql Server
│ │ └── Scripts/ # Scripts de migração
│ ├── ExternalIntegrations/ # Integrações externas
│ ├── Logging/ # Configuração de logs
│ ├── Messaging/ # Configuração de mensageria
│ └── Configurations/ # Arquivos de configuração
│
├── Shared/ # Recursos compartilhados
│ ├── Core/ # Núcleo compartilhado
│ ├── Interfaces/ # Contratos globais
│ ├── Utilities/ # Utilitários
│ ├── Extensions/ # Métodos de extensão
│ ├── Constants/ # Constantes globais
│ └── Enums/ # Enumerações globais
│
├── API/ # Camada de apresentação (API)
│ ├── Controllers/ # Controladores REST
│ ├── Middlewares/ # Middlewares
│ ├── Filters/ # Filtros
│ ├── Requests/ # Modelos de requisição ou DTOs
│ ├── Routes/ # Definições de rotas
│ └── Swagger/ # Configuração de documentação
│
├── Tests/ # Testes automatizados
│ ├── UnitTests/ # Testes unitários
│ ├── IntegrationTests/ # Testes de integração
│ └── EndToEndTests/ # Testes ponta a ponta
│
├── Docs/ # Documentação do projeto
│ ├── Requirements/ # Requisitos
│ ├── Diagrams/ # Diagramas UML e de arquitetura
│ ├── Guidelines/ # Padrões de desenvolvimento
│ └── ChangeLogs/ # Histórico de mudanças
│
├── Scripts/ # Scripts de automação
│ └── BuildDeploy/ # Scripts de build e deploy
│
├── Packages/ # Pacotes ou bibliotecas
│ ├── Core/ # Componentes reutilizáveis centrais
│ └── Modules/ # Módulos autônomos do sistema
│
├── Assets/ # Recursos adicionais
│ ├── Images/ # Imagens do sistema
│ ├── Logos/ # Logos e identidades visuais
│ └── Fonts/ # Fontes tipográficas
│
└── README.md # Descrição do projeto
¶ 1. Módulos
¶ 1.1 Tabela de Módulos (SYS_MOH)
| Tipo: Interno | |
|---|---|
| 1º Fase | |
| ID Módulo | Descrição |
| CFG | Configurador |
| SYS | Tabelas de Sistema |
| Tipo: | Operacional |
| 1º Fase | |
| CAD | Cadastros Gerais |
| COM | Compras |
| LOJ | Controle de Lojas |
| CRM | CRM |
| EST | Estoque e Custos (Aprender) |
| FAT | Faturamento |
| FIN | Financeiro |
| SER | Gestão de Serviços |
| 2º Fase | |
| CAC | Call Center |
| CNT | Contabilidade Gerencial |
| ADU | Importação Aduaneira |
| FIS | Livros Fiscais |
| PCP | Planejamento e Controle da Produção |
| RHP | Recursos Humanos |
| WMS | WMS – Gestão de Armazenagem |
| 3º Fase | |
| ATF | Ativo Fixo |
| PEC | Auto Peças |
| CSL | Cargos e Salários |
| QAD | Controle de Auditoria |
| DOC | Controle de Documentos |
| QNC | Controle de Não-Conformidades |
| PMS | Gestão de Projetos |
| INP | Inspeção de Processos |
| MDT | Medicina e Segurança do Trabalho |
| OFI | Oficina |
| PCO | Planejamento e Controle Orçamentário |
| PON | Ponto Eletrônico |
| PFS | Pré Faturamento de Serviço |
| SLP | Recrutamento e Seleção de Pessoal |
| CRD | Sistema de Fidelização e Análise de Crédito |
| TCF | Terminal de Consulta do Funcionário |
| TMS | TMS – Gestão de Transporte (Aprender) |
| TRM | Treinamento |
| VEI | Veículos |
| 4º Fase | |
| ACV | Acessibilidade Visual |
| ORG | Arquitetura Organizacional |
| IAF | Automação Fiscal |
| GPR | Gerenciamento de Pesquisa e Resultado |
| AGR | Gestão Agroindústria |
| SGA | Gestão Ambiental |
| GCV | Gestão Comercial do Varejo |
| GCT | Gestão de Contratos |
| GFE | Gestão de Frete Embarcador |
| GRI | Gestão de Riscos |
| HSP | Gestão Hospitalar |
| JUR | Gestão Jurídica |
| LOG | Monitoramento de Desempenho Logístico |
| APT | Processos Trabalhistas |
¶ 1.2. Módulos do Sistema e Padrões
Os módulos do sistema SSAG.Core são organizados em duas categorias principais: Internos e Operacionais. Essa separação tem como objetivo facilitar o entendimento e a estruturação do sistema, diferenciando as funcionalidades acessíveis aos usuários finais das funções de suporte técnico e estruturação do sistema.
¶ 1.2.1. Módulos Internos
Os módulos internos são responsáveis pelo funcionamento técnico e pela estrutura de suporte do sistema. Eles não são acessados diretamente pelos usuários finais e são essenciais para o desenvolvimento, configuração e manutenção do SSAG.Core.
| ID Módulo | Descrição | Função |
|---|---|---|
| SYS | Tabelas de Sistema | Gerencia a estrutura básica das tabelas do sistema. |
| Tabelas: | ||
| SYS_BDC | Dicionário de Campos | Armazena informações técnicas sobre os campos utilizados no sistema. |
| SYS_TGH | Tabelas Genéricas | Tabelas comuns reutilizáveis em múltiplos módulos e processos. |
| SYS_MNH | Menus | Controla a organização e exibição dos menus do sistema. |
| SYS_MOH | Módulos | Registro técnico dos módulos do sistema e suas configurações. |
| CFG | Configurador | Ferramenta para configuração e personalização do sistema. |
Principais Características dos Módulos Internos:
- Uso Técnico: Exclusivo para administradores e desenvolvedores.
- Finalidade: Garantir a integridade, a estrutura e a flexibilidade do sistema.
- Exemplos de Tabelas:
SYS_BDT– Registro de Tabelas do Sistema.SYS_BDC– Dicionário de Campos.
¶ 1.2.2. Módulos Operacionais
Os módulos operacionais são as áreas funcionais do sistema, diretamente utilizadas pelos usuários finais para executar tarefas específicas e realizar a gestão de processos empresariais. Eles representam as funcionalidades principais do sistema.
| ID Módulo | Descrição | Função |
|---|---|---|
| CAD | Cadastros Gerais | Gerencia informações principais, como clientes, fornecedores e pessoas. |
| COM | Compras | Controle de pedidos e processos relacionados a compras. |
| CRM | CRM | Gestão de relacionamento com clientes e oportunidades. |
| EST | Estoque e Custos | Gestão de produtos, movimentação de estoque e análise de custos. |
| FAT | Faturamento | Emissão e controle de notas fiscais e faturamento. |
| FIN | Financeiro | Controle de contas a pagar, receber e fluxo de caixa. |
| LOJ | Controle de Lojas | Gerenciamento de operações em pontos de venda e lojas. |
| SER | Gestão de Serviços | Controle de ordens de serviço e prestação de serviços. |
Principais Características dos Módulos Operacionais:
- Uso Funcional: Acessado por diferentes departamentos e usuários finais.
- Finalidade: Facilitar a execução de processos empresariais e operacionais.
- Exemplos de Tabelas:
CAD_CLH– Cadastro de Clientes.FIN_LPH– Lançamentos a Pagar.FAT_NFH– Notas Fiscais.
¶ 1.2.3. Diferença entre Interno e Operacional
| Critério | Interno | Operacional |
|---|---|---|
| Acesso | Administradores e Desenvolvedores. | Usuários finais. |
| Finalidade | Suporte técnico e estruturação. | Gestão e operação de processos. |
| Visibilidade | Não aparece para usuários finais. | Acessível nos menus do sistema. |
| Exemplos | Configurador, Dicionário de Campos. | Compras, Financeiro, Estoque. |
¶ 1.2.4. Explicação do Tipo
Os módulos são classificados como Interno ou Operacional com base no seu uso:
- Interno: Gerencia a estrutura técnica do sistema e serve como base para o funcionamento dos módulos operacionais.
- Operacional: Representa funcionalidades de negócios e processos empresariais, acessíveis aos usuários finais através dos menus.
¶ 2. Menus e Ambientes
Menus e ambientes organizam as funcionalidades do sistema em interfaces acessíveis e intuitivas.
- Estrutura de Menu:
- Menu Principal
- Submenus organizados por módulos
- Exemplo de Codificação:
- Menu Principal:
SSAG_MENU_PRINCIPAL - Submenu de Vendas:
VEN_MENU_OPCOES
- Menu Principal:
¶ 3. Base de Dados
Conceitos e padrões aplicados na estruturação da base de dados do sistema.
- Banco Relacional
- Diretrizes para estruturação:
¶ Diagrama da Base de Dados
¶ 3.0 DomainDataType
Este documento detalha a implementação e uso de DataTypes personalizados, validações específicas e Value Objects no SSAG.Core, com o objetivo de garantir consistência, flexibilidade e escalabilidade no desenvolvimento do sistema.
A abordagem apresentada combina:
-
Enumerações (DomainDataType) para abstração de tipos de dados.
-
Value Objects para encapsular lógica de validação e operações relacionadas.
-
Validações personalizadas para dados como CPF, CNPJ, CEP, telefone, entre outros.
¶ 3.1 Tabelas do Sistema (SYS_BDT)
Tabela que registra as entidades do banco de dados e classes do software.
- Composição do Id da Tabelas:
[3 dígitos ID do Módulo]_[2 dígitos contexto + 1 Hierarquia ou Combinação exclusiva]
Exemplo:
| Módulo de Cadastros | Separador | Clientes | Sufixo |
|---|---|---|---|
| CAD | _ | CL | H |
Resultado:
CAD_CLH - Cadastro de Clientes
| TAH_ID | TAH_PREFIXO | TAH_NOME | TAH_DESCRICAO |
|---|---|---|---|
| ADU_PLH | PLH | PLI | Registro principal de Pedidos de Licença de Importação. |
| ADU_PLI | PLI | Itens da PLI | Detalhamento dos itens associados a uma PLI. |
| CAC_GAH | GAH | Grupo de Atendimento | Definição e agrupamento de clientes ou unidades de suporte para atendimento. |
| CAD_CLH | CLH | CLIENTE | Cadastro completo de clientes, incluindo dados gerais e contatos. |
| CAD_FCH | FCH | FUNCIONÁRIO | Registro de funcionários com informações de RH. |
| CAD_FNH | FNH | FORNECEDOR | Cadastro de fornecedores com detalhes de contrato e contato. |
| CAD_PSH | PSH | PESSOA | Cadastro genérico de pessoas físicas e jurídicas. |
| CAD_SCH | SCH | SÓCIOS | Registro de sócios e acionistas da empresa. |
| CAD_TPH | TPH | TRANSPORTADORA | Cadastro de empresas de transporte e logística. |
| CFG_MAI | MAI | Configuração de servidores e templates de e-mail para o sistema. | |
| CNT_PCC | PCC | PLANO DE CONTAS | Estrutura hierárquica para controle contábil e financeiro. |
| COM_PCH | PCH | Pedido de Compra | Registro principal de pedidos de compra emitidos. |
| COM_PCI | PCI | Itens de Pedido de Compra | Detalhamento dos itens incluídos em pedidos de compra. |
| CRM_ODH | ODH | Oportunidades | Gerenciamento de oportunidades comerciais e negociações. |
| EST_PRH | PRH | Produto | Cadastro de produtos e serviços disponíveis no sistema. |
| FAT_NFH | NFH | NOTA FISCAL | Registro de notas fiscais emitidas ou recebidas. |
| FAT_NFI | NFI | ITENS DE NOTA FISCAL | Detalhamento dos itens contidos em notas fiscais. |
| FIN_LPH | LPH | LANÇAMENTOS A PAGAR | Controle financeiro de contas a pagar. |
| FIN_LRH | LRH | LANÇAMENTOS A RECEBER | Controle financeiro de contas a receber. |
| FIS_REH | REH | Registro de Entradas | Controle fiscal das entradas de mercadorias ou serviços. |
| FIS_RSH | RSH | Registro de Saídas | Controle fiscal das saídas de mercadorias ou serviços. |
| LOJ_PDH | PDH | PDV | Cadastro e configuração de Pontos de Venda (PDV). |
| PCP_EPH | EPH | ESTRUTURA DE PRODUTOS | Estrutura detalhada de composição de produtos e insumos. |
| PCP_OPH | OPH | ORDEM DE PRODUÇÃO | Planejamento e execução de ordens de produção. |
| RHP_FPH | FPH | Cálculo da Folha de Pagamento | Controle e processamento de folha de pagamento. |
| SER_OSH | OSH | Ordem de Serviço | Registro de ordens de serviço para clientes ou manutenção. |
| SYS_MNH | MNH | Menus | Estrutura e configuração dos menus do sistema. |
| SYS_MOH | MOH | Módulos | Cadastro e organização dos módulos do sistema. |
| SYS_BDT | BDT | Base de Dados - Tabelas | Cadastro e controle das tabelas do sistema. |
| SYS_BDC | BDC | Base de Dados - Campos (Dicionário de Campos) | Documentação de todos os campos do sistema. |
| SYS_TGH | TGH | Tabelas Genéricas | Tabelas com dados compartilhados entre módulos. |
| WMS_EEH | EEH | Endereços de Estoque | Localizações específicas para armazenagem dentro do estoque. |
| WMS_LAH | LAH | Locais de Armazenagem | Definição e gestão de áreas gerais de armazenagem. |
¶ 3.2 Dicionário de Campos (SYS_BDC)
O dicionário de campos (SYS_BDC) é utilizado para gerenciar as características dos campos de tabelas do sistema. Ele define como os campos devem ser apresentados, validados e utilizados em telas, relatórios e processos internos.
¶ Atualizações na Classe SYS_BDC (01/12/2024)
public class SYS_BDC
{
[Key]
[Required]
[MaxLength(10)]
public string Nome { get; set; } // Nome técnico do campo.
[Required]
public int Ordem { get; set; } // Ordem de exibição no formulário.
[MaxLength(10)]
public string CampoPai { get; set; } // Nome do campo "pai" (ex.: IdMunicipio)
public string CamposVirtuais { get; set; } // Lista separada por vírgulas (ex.: NomeMunicipio, CodIBGE)
[Required]
[MaxLength(10)]
public string IdTabela { get; set; } // ID da tabela associada.
[MaxLength(25)]
public GuidShort IdGrupo { get; set; } // Grupo ao qual o campo pertence.
[MaxLength(25)]
public GuidShort IdGuia { get; set; } // Identificador da guia de exibição.
[MaxLength(200)]
public string Descricao { get; set; } // Descrição do campo.
[MaxLength(2000)]
public string Ajuda { get; set; } // Texto de ajuda para o campo.
[Required]
[MaxLength(10)]
public DomainDataType Tipo { get; set; } // Tipo de dado (VARCHAR, INT, etc.)
public int Tamanho { get; set; } // Tamanho máximo do campo.
public int? Decimal { get; set; } // Número de casas decimais (se aplicável).
public bool PK { get; set; } // Indica se o campo é chave primária.
public bool SomenteLeitura { get; set; } // Define se o campo é somente leitura.
public bool Obrigatorio { get; set; } // Indica se o campo é obrigatório.
public bool Virtual { get; set; } // Indica se é um campo virtual.
public bool Password { get; set; } // Indica se o campo deve ser mascarado (ex.: senha).
[MaxLength(25)]
public GuidShort IdConsulta { get; set; } // Identificador de uma consulta associada.
public DadosOrigemType DadosOrigem { get; set; } // Origem dos dados (Query, Lista, Enum, ConsultaSalva)
public string DadosValores { get; set; } // Lista de valores para Lista/Enum (separados por vírgulas)
public string DadosQueryVirtual { get; set; } // Query associada para dados dinâmicos.
public string ValorPadrao { get; set; } // Valor padrão para o campo (se aplicável)
// Relacionamento com Tabela (SYS_BDT)
public virtual SYS_BDT Tabela { get; set; }
}
¶ Enumeração DadosOrigemType
public enum DadosOrigemType
{
Lista, // Lista de valores fixos
Enum, // Enumeração
Query, // Query direta (SQL, LINQ)
ConsultaSalva // Nome da consulta previamente salva
}
¶ DynamicSearchService para Consultas Dinâmicas
¶ Caminho: SSAG.Core.Application/Services/DynamicSearchService.cs
public class DynamicSearchService : IDynamicSearchService
{
public async Task<IEnumerable<dynamic>> BuscarDadosAsync(DadosOrigemRequest request)
{
switch (request.DadosOrigem)
{
case DadosOrigemType.ConsultaSalva:
// Executa consulta salva
break;
case DadosOrigemType.Query:
// Executa query direta
break;
case DadosOrigemType.Lista:
// Processa lista estática
break;
case DadosOrigemType.Enum:
// Processa enumeração
break;
default:
throw new InvalidOperationException("Origem de dados inválida.");
}
}
}
¶ Estrutura e Descrição dos Campos da Classe SYS_BDC
| Propriedade | Descrição | Como preencher | Exemplo |
|---|---|---|---|
| BDC_Nome | Nome técnico do campo. | Nome único que identifica o campo na tabela. | CLH_NOME para Nome do Cliente. |
| BDC_Ordem | Ordem de exibição no formulário ou interface. | Número sequencial indicando a posição. | 1 para o primeiro campo, 2 para o segundo. |
| BDC_CampoPai | Nome do campo pai que determina a dependência. | Nome do campo "pai" relacionado a este campo. | CLH_IdEstado para dependência de Cidade. |
| BDC_CamposVirtuais | Lista de campos adicionais exibidos na interface. | Nomes separados por vírgula. | NomeCidade,CodigoIBGE. |
| BDC_IdTabela | Identificador técnico da tabela associada. | Código da tabela no padrão [Módulo]_[Tabela]. |
CAD_CLH para Clientes. |
| BDC_IdGrupo | Identificador do grupo de campos. | Código que agrupa campos logicamente. | DADOS_PESSOAIS. |
| BDC_IdGuia | Identificador da guia ou aba de exibição. | Nome técnico da guia. | GUIA_ENDERECO. |
| BDC_Descricao | Descrição amigável para exibição na interface. | Texto descritivo claro e objetivo. | Nome do Cliente. |
| BDC_Ajuda | Texto explicativo para orientar o preenchimento do campo. | Mensagem curta e informativa. | Informe o nome completo do cliente. |
| BDC_Tipo | Tipo de dado armazenado. | Selecionar o tipo correspondente na enumeração DomainDataType. |
VARCHAR para texto variável. |
| BDC_Tamanho | Tamanho máximo do campo. | Número de caracteres ou dígitos. | 50 para até 50 caracteres. |
| BDC_Decimal | Número de casas decimais. | Número de casas decimais aplicável a valores monetários ou flutuantes. | 2 para valores monetários. |
| BDC_PK | Indica se o campo é uma chave primária. | true para chave primária, false caso contrário. |
true para campo ID. |
| BDC_SomenteLeitura | Define se o campo será apenas leitura. | true para somente leitura, false para edição permitida. |
true para campos calculados. |
| BDC_Obrigatorio | Define se o campo é obrigatório. | true para obrigatórios, false para opcionais. |
true para Nome. |
| BDC_Virtual | Indica se o campo é virtual (não persistido no banco). | true para virtuais, false caso contrário. |
true para campos de exibição calculada. |
| BDC_Password | Define se o campo será mascarado. | true para exibir caracteres mascarados, false para exibição normal. |
true para senha. |
| BDC_IdConsulta | Código de consulta associada ao campo. | Código único da consulta configurada. | CONSULTA_CLIENTE. |
| BDC_DadosOrigem | Origem dos dados para preenchimento. | Selecionar na enumeração DadosOrigemType: Lista, Enum, Query, ou ConsultaSalva. |
Query para dados dinâmicos. |
| BDC_DadosValores | Valores fixos para listas ou enums. | Valores separados por vírgulas. | Ativo,Inativo. |
| BDC_DadosQueryVirtual | Query SQL ou LINQ associada ao campo. | String contendo a consulta. | SELECT Id, Nome FROM tCidades. |
| BDC_ValorPadrao | Valor padrão do campo. | Valor inicial predefinido. | "Brasil" para país. |
¶ Exemplos de Configuração
¶ Campo Normal
new SYS_BDC
{
Nome = "CLH_NOME",
IdTabela = "CLH",
Ordem = 1,
Tipo = DomainDataType.VARCHAR,
Tamanho = 50,
Obrigatorio = true,
Descricao = "Nome do Cliente"
};
¶ Campo com Consulta Vinculada
new SYS_BDC
{
Nome = "CLH_IdCidade",
IdTabela = "CLH",
Ordem = 2,
Tipo = DomainDataType.INT,
CampoPai = "CLH_IdEstado",
BDC_IdConsulta = "CONSULTA_CIDADES",
Descricao = "Cidade vinculada ao estado."
};
¶ Campo com Campos Virtuais
new SYS_BDC
{
Nome = "CLH_IdCidade",
IdTabela = "CLH",
Ordem = 3,
Tipo = DomainDataType.INT,
CampoPai = "CLH_IdEstado",
CamposVirtuais = "NomeCidade,CodigoIBGE",
BDC_DadosQueryVirtual = "SELECT Id, Nome, CodigoIBGE FROM tCidades WHERE UF = @UF",
Descricao = "Cidade com nome e código IBGE."
};
¶ Decisões e Benefícios
¶ Decisões
-
Campos Virtuais:
- Campos virtuais são definidos em
CamposVirtuaise gerados dinamicamente no backend para facilitar a exibição na interface.
- Campos virtuais são definidos em
-
Consultas Dinâmicas:
- Utilizar
BDC_IdConsultaouBDC_DadosQueryVirtualpara gerar dados automaticamente na interface, conforme a configuração do campo.
- Utilizar
-
Campos Dependentes:
- Associar dependências usando
CampoPaipara vincular hierarquias lógicas. - Exemplo: Um campo de Cidade pode depender de um campo de Estado (
CLH_IdEstado → CLH_IdCidade).
- Associar dependências usando
¶ Benefícios
-
Flexibilidade:
- Permite fácil configuração de campos dinâmicos sem necessidade de alterações estruturais no código.
-
Automação:
- Reduz o tempo de desenvolvimento ao gerar consultas e interfaces automaticamente com base em configurações.
-
Escalabilidade:
- Adapta-se facilmente à adição de novos campos, guias e dependências no sistema, mantendo consistência e desempenho.
¶ Exemplos de Configuração
¶ Campo Normal
| Propriedade | Configuração | Descrição |
|---|---|---|
| Nome | CLH_NOME | Nome do Cliente |
| IdTabela | CLH | Tabela de Clientes |
| Tipo | VARCHAR | Texto |
| Tamanho | 50 | Até 50 caracteres |
| Obrigatorio | Sim | O campo é obrigatório |
{
"Nome": "CLH_NOME",
"IdTabela": "CLH",
"Ordem": 1,
"CampoPai": "",
"CamposVirtuais": "",
"BDC_DadosOrigem": null,
"BDC_DadosQueryVirtual": "",
"Tipo": "VARCHAR",
"Tamanho": 50,
"Obrigatorio": true,
"Descricao": "Nome do Cliente"
}
¶ Campo com Consulta
| Propriedade | Configuração | Descrição |
|---|---|---|
| Nome | CLH_IdCidade | Código da Cidade |
| CampoPai | CLH_IdEstado | Dependência para IdEstado |
| CamposVirtuais | NomeCidade,CodigoIBGE | Campos exibidos na interface |
| IdConsulta | CONSULTA_CIDADES | Consulta associada |
| Tipo | INT | Número inteiro |
| Obrigatorio | Sim | O campo é obrigatório |
| DadosQueryVirtual | SELECT Id, Nome, CodigoIBGE FROM tCidades WHERE UF = @UF |
Query para cidades |
{
"Nome": "CLH_IdCidade",
"IdTabela": "CLH",
"Ordem": 2,
"CampoPai": "CLH_IdEstado",
"CamposVirtuais": "NomeCidade,CodigoIBGE",
"BDC_DadosOrigem": "Query",
"BDC_DadosQueryVirtual": "SELECT Id, Nome, CodigoIBGE FROM tCidades WHERE UF = @UF",
"Tipo": "INT",
"Tamanho": null,
"Obrigatorio": true,
"Descricao": "Código da Cidade",
"IdConsulta": "CONSULTA_CIDADES"
}
¶ Campo Virtual
| Propriedade | Configuração | Descrição |
|---|---|---|
| Nome | NomeCidade | Nome da Cidade |
| CampoPai | CLH_IdCidade | Associado ao campo IdCidade |
| Tipo | CHAR | Texto |
| SomenteLeitura | Sim | Apenas exibido na interface |
{
"Nome": "CLH_NomeMunicipio",
"IdTabela": "CLH",
"Ordem": 5,
"CampoPai": "CLH_IdMunicipio",
"CamposVirtuais": "NomeMunicipio,CodigoIBGE",
"BDC_DadosOrigem": "Query",
"BDC_DadosQueryVirtual": "SELECT Id, NomeMunicipio,CodigoIBGE FROM tMunicipios WHERE id = @id",
"Tipo": "VARCHAR",
"Tamanho": "120",
"Virtual": true,
"Obrigatorio": false,
"Descricao": "Código do Município"
}
¶ Decisões Tomadas
¶ 1. Propriedade Virtual:
- Indica que o campo não será persistido no banco de dados do cliente.
- Será utilizado somente em DTOs ou no backend para fornecer dados auxiliares (ex.: exibição na interface).
¶ 2. Consulta Virtual (BDC_DadosQueryVirtual):
- Utiliza uma query SQL parametrizada para buscar dados relacionados ao campo.
- Exemplo: Busca pelo Id do município para trazer NomeMunicipio e CodigoIBGE.
¶ 3. Campos Dependentes (CampoPai):
- Relaciona o campo a um pai lógico (CLH_IdMunicipio), permitindo vincular hierarquias de dados (ex.: Estado → Cidade → Bairro).
¶ 4. Campos Virtuais (CamposVirtuais):
- Define os nomes dos campos que serão gerados no backend, como NomeMunicipio e CodigoIBGE.
¶ Benefícios da Abordagem
¶ 1. Desacoplamento:
- Os campos virtuais não poluem a base de dados com informações redundantes.
- Reduz a complexidade e o tamanho da tabela.
¶ 2. Flexibilidade:
- Permite que dados sejam apresentados ao usuário sem necessidade de persistência física.
- Exemplo: Nome do município exibido na interface.
¶ 3. Eficiência:
- Os dados são obtidos sob demanda com consultas parametrizadas.
- Reduz redundâncias e melhora a escalabilidade.
¶ 4. Automação:
- A geração automática de DTOs e interfaces pode aproveitar a configuração de campos virtuais.
¶ Fluxo de Configuração e Automação
- Configuração no SYS_BDC:
- Preenchimento de todas as propriedades relacionadas.
- Backend:
- Geração automática de classes, DTOs e consultas.
- Interface:
- Exibição dos campos configurados, com suporte a pesquisas dinâmicas e exibição de campos virtuais.
¶ Boas Práticas
- Sempre validar consultas para evitar injeção de SQL.
- Usar
CamposVirtuaispara dependências claras e organizadas. - Testar todas as configurações antes de aplicar no ambiente de produção.
¶ 3.3 SYS_BDA e SYS_BDG (Relações e Hierarquias)
¶ Relações Entre SYS_BDA e SYS_BDG
As entidades SYS_BDA (Grupos) e SYS_BDG (Guias) são estruturadas para organizar tabelas (SYS_BDT) e campos (SYS_BDC) de forma hierárquica, garantindo flexibilidade e facilidade de uso.
¶ Fluxo de Configuração
¶ 1. Criar um Grupo (SYS_BDA)
Os Grupos são a base para organização de guias e campos em uma tabela.
¶ Exemplo de Configuração
{
"Id": "12345",
"IdTabela": "CAD_CLH",
"Nome": "Dados Pessoais",
"Descricao": "Informações básicas de clientes.",
"Ordem": 1,
"Icone": "user-icon"
}
¶ Passos
- Defina o IdTabela correspondente.
- Nomeie o grupo de acordo com sua funcionalidade.
- Adicione uma descrição para documentação.
- Defina a ordem de exibição do grupo no frontend.
- (Opcional) Associe um ícone visual ao grupo.
¶ 2. Associar Guias ao Grupo (SYS_BDG)
As Guias organizam os campos de um grupo em abas ou seções específicas.
¶ Exemplo de Configuração
{
"Id": "67890",
"IdTabela": "CAD_CLH",
"IdGrupo": "12345",
"Nome": "Informações de Contato",
"Descricao": "Endereço, telefone e e-mail.",
"Ordem": 1,
"Icone": "contact-icon"
}
¶ Passos
- Vincule a guia ao IdGrupo correspondente.
- Nomeie a guia para facilitar a identificação.
- Adicione uma descrição para documentação.
- Defina a ordem de exibição dentro do grupo.
- (Opcional) Associe um ícone visual à guia.
¶ 3. Associar Campos à Guia (SYS_BDC)
Os Campos contêm as informações finais a serem exibidas ou armazenadas.
¶ Exemplo de Configuração
{
"Nome": "CLH_NOME",
"IdTabela": "CAD_CLH",
"IdGrupo": "12345",
"IdGuia": "67890",
"Ordem": 1,
"Tipo": "VARCHAR",
"Tamanho": 50,
"Obrigatorio": true,
"Descricao": "Nome completo do cliente."
}
¶ Passos
- Vincule o campo ao IdGuia correspondente.
- Defina o tipo, tamanho e outras propriedades do campo.
- Adicione uma descrição para orientar os usuários.
¶ Exemplos de Agrupamento Visual
¶ Interface para o Usuário Final
Grupos e Guias Aparecem Assim:
- Grupo: Dados Pessoais
- Guia: Informações de Contato
- Campos: Nome, Telefone, E-mail.
- Guia: Endereço
- Campos: Logradouro, Número, CEP, Bairro.
- Guia: Informações de Contato
¶ Exemplo de Mockup Visual
| Grupo: Dados Pessoais | Grupo: Dados Corporativos |
|---|---|
| Guia: Informações de Contato | Guia: Informações Jurídicas |
| Nome: | Razão Social: |
| Telefone: | CNPJ: |
| E-mail: | Inscrição Estadual: |
Com esses exemplos e fluxos, o uso prático das entidades SYS_BDA e SYS_BDG fica mais claro, auxiliando na configuração e no desenvolvimento de interfaces organizadas e intuitivas.
¶ 3.4 Relacionamento de Tabelas (SYS_BDR)
¶ Escopo
Catálogo de relacionamentos entre entidades do domínio (tabelas lógicas) que alimenta o gerador (Domain/EF Core/Migrations/UI) e a interface administrativa.
O DTO utilizado é o RelacionamentoDTO.
¶ 3.4.1 Objetivo
-
Padronizar vínculos entre entidades (1:1, 1:N, N:N).
-
Orquestrar o gerador para criar:
- Propriedades de navigation e FK;
- Fluent API de mapeamento;
- Estruturas de banco (FKs, índices, join table);
- UI (abas, seções, lista inline, rótulos, ordem).
-
Documentar intenções do modelo (descrições, regras, filtros).
¶ 3.4.2 Mapa dos Campos (DTO)
| Campo | Tipo | Obrig. | Descrição |
|---|---|---|---|
| Id | GuidShort | ✅ | Identificador do relacionamento (Guid encurtado). |
| EntidadeOrigem | string(100) | ✅ | Nome lógico da origem (ex.: CAD_PSH). Espelho legível. |
| CampoOrigem | string(50) | ✅ | Campo/coluna-chave da origem (ex.: PSH_Id). Espelho legível. |
| EntidadeDestino | string(100) | ✅ | Nome lógico do destino (ex.: CAD_END). Espelho legível. |
| CampoDestino | string(50) | ✅ | Campo/coluna-chave do destino. Espelho legível. |
| OrigemBDTId | GuidShort? | — | ID da tabela de origem no catálogo BDT. |
| DestinoBDTId | GuidShort? | — | ID da tabela de destino no catálogo BDT. |
| OrigemBDCId | GuidShort? | — | ID do campo de origem no catálogo BDC. |
| DestinoBDCId | GuidShort? | — | ID do campo de destino no catálogo BDC. |
| JoinBDTId | GuidShort? | — | ID da tabela de junção (somente ManyToMany). |
| TipoRelacionamento | RelType | ✅ | OneToOne | OneToMany | ManyToMany. |
| DescricaoRelacionamento | string(255) | — | Texto livre sobre o vínculo. |
| IsAggregate | bool | — | Destino participa do Aggregate Root da origem (DDD). |
| IsOwnership | bool | — | Composição forte (Owned / vida dependente). |
| CascadeOnDelete | bool | — | Deleção em cascata no domínio (e DB quando possível). |
| MinCard | byte? | — | Cardinalidade mínima (0, 1…). |
| MaxCard | byte? | — | Cardinalidade máxima (1, N…). |
| NavigationName | string(60) | — | Nome da navigation ida (origem → destino). |
| InverseNavigation | string(60) | — | Nome da navigation volta (destino → origem). |
| FKNameOverride | string(128) | — | Nome físico da FK (sobrescreve convenção). |
| UiRole | string(60) | — | Rótulo amigável na UI (ex.: “Endereços”). |
| UiOrder | int | — | Ordem de exibição na UI (asc). |
| UiDisplay | UiDisplayType? | — | TREE | TAB | SECTION | INLINE_LIST. |
| IsOptional | bool | — | Vínculo opcional no caso de uso principal. |
| ValidationRule | string(120) | — | Regra funcional resumida. |
| FilterJson | string | — | Filtro/escopo em JSON para listas/queries. |
| Notes | string | — | Observações internas. |
Espelhos x Catálogo
Entidade*/Campo*= espelhos legíveis (nomes).*BDTId/*BDCId= IDs do catálogo (fonte da verdade para o gerador).
¶ 3.4.3 Tipos de Relacionamento e Impactos
¶ A) OneToOne
Domain/EF:
HasOne(x => x.Alvo).WithOne(x => x.Origem).HasForeignKey<Dependente>(fk)
Banco: FK + índice único garantindo 1:1.
Uso: Pessoa ↔ PessoaFisica.
Notas: Com IsOwnership = true, vira Owned Entity (vide 3.4.5-D).
¶ B) OneToMany
Domain/EF:
HasMany(x => x.Colecao).WithOne(x => x.Origem).HasForeignKey(fk)
Banco: FK no lado “many” (coluna + índice/constraint).
Uso: Pessoa ↔ Enderecos, Pedido ↔ Itens.
¶ C) ManyToMany
- Sem join explícita: EF cria tabela de junção automática.
- Com join explícita (
JoinBDTId): gera entidade de junção nomeada.
Banco: Join table com FKs para ambas as pontas.
¶ 3.4.4 Cardinalidade & DDD
- MinCard: 0 → opcional; 1 → obrigatório.
- MaxCard: 1 → máximo um; >1/null → coleção.
Impactos: nullability, validações, UI.
¶ IsAggregate (DDD)
Destino faz parte do agregado da origem. Gerador pode expor Add*/Remove*.
¶ IsOwnership
Destino não vive sem a origem (OwnsOne/OwnsMany).
¶ CascadeOnDelete
Remove dependentes junto da origem. EF: DeleteBehavior.Cascade (quando seguro).
¶ IsOptional
Opcionalidade além da nullability técnica.
¶ 3.4.5 UI & Navegação
| Campo | Uso | Efeito |
|---|---|---|
| UiDisplay | TREE/TAB/SECTION/INLINE_LIST | Forma de exibição. |
| UiRole | Texto curto | Rótulo visível na UI. |
| UiOrder | Inteiro | Ordenação. |
| NavigationName | Nome C# | Navigation ida. |
| InverseNavigation | Nome C# | Navigation inversa. |
Diretrizes:
- TAB: aba dedicada.
- SECTION: bloco na página.
- INLINE_LIST: grade compacta.
- TREE: hierarquia.
- Singular/plural coerente.
¶ 3.4.6 Regras & Filtros
¶ A) ValidationRule
Ex.: “PJ exige 1 endereço fiscal”.
¶ B) FilterJson
{
"where": [
{ "field": "Status", "op": "=", "value": "Ativo" },
{ "field": "EmpresaId", "op": "=", "value": "{CurrentTenantId}" }
],
"orderBy": [{ "field": "Nome", "dir": "asc" }],
"include": ["Enderecos"]
}
Placeholders: {CurrentUserId}, {CurrentTenantId}, {Now}…
¶ 3.4.7 Catálogo BDT/BDC e Nomes Físicos
OrigemBDTId/DestinoBDTId: resolve entidades por ID.OrigemBDCId/DestinoBDCId: amarra FK ao campo correto.JoinBDTId: em ManyToMany nomeada.FKNameOverride: controla nome físico.
¶ 3.4.8 Passo a Passo de Preenchimento
- Origem:
OrigemBDTId+EntidadeOrigem. - Campo origem:
CampoOrigem(+OrigemBDCId). - Destino:
DestinoBDTId+EntidadeDestino. - Campo destino:
CampoDestino(+DestinoBDCId). - Tipo:
TipoRelacionamento(+JoinBDTIdse N:N). - Cardinalidade & DDD:
MinCard,MaxCard,IsAggregate,IsOwnership,CascadeOnDelete,IsOptional. - UI/Navegação:
UiDisplay,UiRole,UiOrder,NavigationName,InverseNavigation. - Regras/Filtros:
ValidationRule,FilterJson,DescricaoRelacionamento,Notes. - Nomes físicos:
FKNameOverride. - Salvar e revisar antes de promover.
¶ 3.4.9 Exemplos
¶ (1) Pessoa 1:N Enderecos
{
"EntidadeOrigem": "CAD_PSH",
"CampoOrigem": "PSH_Id",
"EntidadeDestino": "CAD_END",
"CampoDestino": "END_PessoaId",
"OrigemBDTId": "psh_ab12cd",
"DestinoBDTId": "end_34ef56",
"TipoRelacionamento": "OneToMany",
"NavigationName": "Enderecos",
"InverseNavigation": "Pessoa",
"UiDisplay": "INLINE_LIST",
"UiRole": "Endereços",
"UiOrder": 10,
"IsAggregate": true,
"CascadeOnDelete": true,
"ValidationRule": "Endereço fiscal obrigatório para PJ",
"FilterJson": "{\"where\":[{\"field\":\"Status\",\"op\":\"=\",\"value\":\"Ativo\"}]}"
}
¶ (2) Pessoa 1:1 PessoaFisica
{
"EntidadeOrigem": "CAD_PSH",
"CampoOrigem": "PSH_Id",
"EntidadeDestino": "CAD_PSF",
"CampoDestino": "PSF_PessoaId",
"TipoRelacionamento": "OneToOne",
"NavigationName": "PessoaFisica",
"InverseNavigation": "Pessoa",
"UiDisplay": "SECTION",
"UiRole": "Pessoa Física",
"UiOrder": 20,
"IsAggregate": true,
"CascadeOnDelete": true,
"MinCard": 1,
"MaxCard": 1,
"FKNameOverride": "FK_PSF_PSH"
}
¶ (3) Usuario N:N Perfil com join explícita
{
"EntidadeOrigem": "SYS_USR",
"CampoOrigem": "USR_Id",
"EntidadeDestino": "SYS_PER",
"CampoDestino": "PER_Id",
"TipoRelacionamento": "ManyToMany",
"JoinBDTId": "USR_PER",
"NavigationName": "Perfis",
"InverseNavigation": "Usuarios",
"UiDisplay": "TAB",
"UiRole": "Perfis",
"UiOrder": 5
}
¶ 3.4.10 Erros Comuns
| Mensagem | Causa | Correção |
|---|---|---|
| “Id field is required” | Backend não gerou GuidShort. | Gerar no servidor ou preencher antes de persistir. |
| “Valor não é GuidShort válido” | *BDTId/*BDCId preenchidos com nomes. | Usar IDs do catálogo. |
| Campo destino não carrega | DestinoBDTId ausente. | Definir tabela destino antes de carregar campos. |
| Navigation duplicada | Nome já existe. | Ajustar nomes; rodar gerador. |
| Multiple cascade paths | Várias FKs em cascade. | Manter uma; demais Restrict/ClientCascade. |
¶ 3.4.11 Boas Práticas
- Preferir IDs do catálogo (BDT/BDC) quando disponíveis.
- Usar plural/singular corretos em
NavigationName/InverseNavigation. - Manter
ValidationRulecurta; detalhar em página própria se necessário. - Centralizar escopo em
FilterJson. - Em N:N, usar
JoinBDTIdse precisar atributos na junção.
¶ SYS_BDC Novas Validações e Ajustes Realizados
Este documento apresenta as atualizações de validações e ajustes aplicados à entidade SYS_BDC, alinhando com novas regras e necessidades identificadas no projeto SSAG3.0.
¶ 1. Nome do Campo
- Regra Atualizada:
- Obrigatório.
- Deve seguir o padrão
[Prefixo]_[Nome]. - Apenas a primeira letra após o caractere
_pode ser maiúscula; as demais devem ser minúsculas ou números.
- Expressão Regular Atualizada:
^[A-Z]{3}_[A-Z][a-z0-9]{1,}$ - Mensagem de Erro:
- "O campo Nome é obrigatório."
- "O Nome deve seguir o padrão: [Prefixo]_[Nome], com apenas a primeira letra maiúscula."
¶ 2. Descrição
- Regra Atualizada:
- Obrigatório.
- Deve conter uma descrição clara e objetiva.
- Planejamento para utilização futura de IA na validação semântica.
- Mensagem de Erro:
- "O campo Descrição é obrigatório."
¶ 3. IdTabela
- Regra Atualizada:
- Obrigatório.
- Deve conter 3 caracteres do módulo,
_, e 3 caracteres únicos. - Apenas tabelas válidas podem ser referenciadas.
- Mensagem de Erro:
- "O campo IdTabela é obrigatório."
- "O formato do IdTabela deve ser
[MOD]_XXX."
¶ 4. Campos Virtuais
- Regra Atualizada:
- Permitido apenas para tipos específicos (
Query,Lista,Enum,ConsultaSalva). - Deve ser validado conforme o
DadosOrigemType.
- Permitido apenas para tipos específicos (
- Mensagem de Erro:
- "Os Campos Virtuais devem corresponder ao tipo de origem configurado."
¶ 5. Tamanho e Decimais
- Regra Atualizada:
- Tamanho: Obrigatório para tipos
CHAR,VARCHAR,JSON,XMLeBLOB. Deve respeitar limites por tipo. - Decimais: Aplicável apenas para tipos
DECIMAL,FLOATeCURRENCY. Deve estar no intervalo apropriado.
- Tamanho: Obrigatório para tipos
- Mensagem de Erro:
- "O campo Tamanho é obrigatório para o tipo especificado."
- "O número de decimais deve estar entre 2 e 4."
¶ 6. Chave Primária (PK)
- Regra Atualizada:
- Apenas um campo pode ser marcado como PK por tabela.
- Mensagem de Erro:
- "Apenas um campo pode ser definido como Chave Primária por tabela."
¶ 7. DadosOrigem
- Regra Atualizada:
- Deve estar entre as opções definidas no
DadosOrigemType. - Configuração específica para cada tipo:
Lista: Valores separados por vírgulas.Query: Deve conter uma consulta SQL válida.Enum: Deve referenciar um enum declarado.ConsultaSalva: ID de consulta salva válido.
- Deve estar entre as opções definidas no
- Mensagem de Erro:
- "O campo DadosOrigem é inválido."
- "Os valores devem ser compatíveis com o tipo de DadosOrigem configurado."
¶ Atualizações na Classe SYS_BDC
public class SYS_BDC
{
[Key]
[Required]
public GuidShort Id { get; set; } // Identificador único do Campo.
[Required]
[MaxLength(10)]
public string IdTabela { get; set; } // Identificador único da tabela.
[Required]
[MaxLength(120)]
public string Nome { get; set; } // Nome do Campo.
[Required]
[MaxLength(500)]
public string Descricao { get; set; } // Descrição do Campo.
[Required]
public int Ordem { get; set; } // Ordem de exibição do Campo.
public string? CamposVirtuais { get; set; } // Lista de Campos Virtuais.
[MaxLength(2000)]
public string Ajuda { get; set; } // Texto de ajuda para o Campo.
[Required]
public DomainDataType Tipo { get; set; } // Tipo de dado (VARCHAR, INT, etc.).
public int? Tamanho { get; set; } // Tamanho máximo do campo.
public int? Decimal { get; set; } // Casas decimais (se aplicável).
public bool PK { get; set; } // Indica se é chave primária.
public bool Obrigatorio { get; set; } // Indica se o campo é obrigatório.
public DadosOrigemType? DadosOrigem { get; set; } // Origem dos Dados.
public string? DadosValores { get; set; } // Valores para listas ou enums.
public string? DadosQueryVirtual { get; set; } // Query associada ao Campo.
}
¶ Conclusão
Com essas validações atualizadas, a entidade SYS_BDC está preparada para garantir consistência, flexibilidade e conformidade com as regras do sistema SSAG3.0. Para dúvidas ou sugestões, entre em contato com o time de desenvolvimento.
¶ Regras Gerais
- Utilize a nomenclatura padronizada para todos os campos.
- Certifique-se de que todos os campos obrigatórios estejam preenchidos corretamente.
- Consulte o dicionário de campos antes de criar ou alterar tabelas no sistema.
¶ 4. Tabelas Genéricas
Tabelas utilizadas de forma transversal por vários módulos.
- Exemplos:
- Empresas e Filiais:
GEN_EMPR - Estados e Municípios:
GEN_UF - Moedas:
GEN_MOEDA
- Empresas e Filiais:
¶ 5. Grupos: Empresas, Filiais e Outros
Estrutura para organizar e gerenciar múltiplas entidades no sistema.
- Empresas: Gestão centralizada.
- Filiais: Parâmetros específicos por unidade.
- Outros grupos: Customizáveis para diferentes necessidades.
¶ 6. Usuários e Permissões
Definições de níveis de acesso e perfis de usuários.
- Perfis padrão:
- Administrador: Acesso total ao sistema.
- Usuário Operacional: Acesso a módulos específicos.
- Estrutura de permissões:
- Baseadas em tabelas: Controle por linha.
- Baseadas em funções: Controle por ação.
¶ 7. Pastas Padrões
Diretórios organizados para armazenar arquivos gerados e processados pelo sistema.
- Exemplo:
Importação:/files/importExportação:/files/exportLogs:/files/logs
¶ 8. Repositório de Imagens
Centralização de imagens e arquivos multimídia utilizados pelo sistema.
- Estrutura sugerida:
/images/cadastros/images/documentos
¶ 9. Auditorias (Logs do Sistema)
Registros de ações realizadas no sistema para rastreabilidade e segurança.
- Exemplo de Eventos:
- Inclusão, alteração, exclusão de dados.
- Login/logout de usuários.
- Armazenamento:
- Tabelas específicas:
LOG_EVENTOS,LOG_ACESSOS - Logs arquivados por período para otimizar a performance.
- Tabelas específicas:
¶ Abordagens para Validação no Backend e Frontend
Esta documentação descreve as abordagens recomendadas para implementar validações no backend e frontend de forma eficiente, garantindo consistência, flexibilidade e manutenibilidade. A escolha da melhor abordagem depende das necessidades do projeto.
¶ 1. Abordagens de Validação
| Abordagem | Descrição | Vantagens | Desvantagens | Uso Ideal |
|---|---|---|---|---|
| Centralizar no Shared | Validações compartilhadas entre backend e frontend. | - Simplicidade - Consistência |
- Não suporta validações dinâmicas | Projetos pequenos e estáticos |
| Sincronizar via API | Regras centralizadas no backend, consumidas dinamicamente no frontend. | - Flexibilidade - Centralização |
- Complexidade maior - Latência |
Projetos grandes e dinâmicos |
| Abordagem Híbrida | Combina centralização (Shared) com sincronização (API). | - Equilíbrio - Resiliência |
- Complexidade moderada | Projetos robustos e complexos |
¶ 2. Implementação das Abordagens
¶ 2.1 Centralizar no Shared
Nesta abordagem, as validações são definidas no projeto Shared, compartilhado entre o backend e o frontend.
Exemplo de Implementação (C#):
public class TabelasDTOValidator : AbstractValidator<TabelasDTO>
{
public TabelasDTOValidator()
{
RuleFor(x => x.Nome)
.NotEmpty().WithMessage("O nome é obrigatório.")
.MaximumLength(120).WithMessage("Máximo de 120 caracteres.");
}
}
Uso no Backend:
services.AddValidatorsFromAssemblyContaining<TabelasDTOValidator>();
Uso no Frontend:
As mesmas regras podem ser reutilizadas no frontend via bibliotecas compatíveis.
¶ 2.2 Sincronizar Validações via API
As regras são centralizadas no backend e expostas dinamicamente para o frontend via API.
Backend - Exemplo de Endpoint:
[HttpGet("validation-rules")]
public IActionResult GetValidationRules()
{
return Ok(new
{
IdRegex = @"^[A-Z]{3}_[A-Z]{2}[A-Z0-9]$",
PrefixoMaxLength = 5,
NomeMaxLength = 120
});
}
Frontend - Consumo do Endpoint:
protected override async Task OnInitializedAsync()
{
var rules = await Http.GetFromJsonAsync<ValidationRules>("api/tabelas/validation-rules");
ValidatorRules = rules;
}
¶ 2.3 Abordagem Híbrida
Combina regras fixas no Shared com regras dinâmicas via API.
Regras no Shared (Fixas):
public class TabelasDTOValidator : AbstractValidator<TabelasDTO>
{
public TabelasDTOValidator()
{
RuleFor(x => x.Nome)
.NotEmpty().WithMessage("O nome é obrigatório.")
.MaximumLength(120).WithMessage("Máximo de 120 caracteres.");
}
}
Regras Dinâmicas via API:
Mesmo exemplo do tópico 2.2 Sincronizar via API.
Uso Ideal:
- Regras fixas no Shared garantem funcionamento básico.
- Regras dinâmicas garantem flexibilidade adicional.
¶ 3. Diagrama de Validações
¶ 4. Fluxo de Validação Sugerido
- Receber os Dados:
- Dados são recebidos via DTO ou entrada de formulário.
- Aplicar Validações no DTO:
- Validações com Data Annotations ou Fluent Validation.
- Consultar Regras no Banco:
- Validações dinâmicas via ValidationService.
- Retornar Mensagens de Erro:
- Respostas claras com erros ou confirmações.
¶ 5. Benefícios da Abordagem Híbrida
- Manutenção Simples: Regras fixas no código, dinâmicas no banco.
- Flexibilidade: Alteração rápida das regras.
- Escalabilidade: Suporte a múltiplos contextos e clientes.
- Segurança: Validações robustas reduzem erros e inconsistências.
¶ 6. Exemplo Prático de Validação Dinâmica
¶ Estrutura da Tabela
Tabela: SYS_VALIDACAO
+--------------+-------------+---------------------------+
| Campo | Tipo | Regra |
+--------------+-------------+---------------------------+
| Nome | VARCHAR(10) | NOT NULL, MAX(10) |
| IdTabela | VARCHAR(10) | NOT NULL |
| Ordem | INT | MIN(1) |
+--------------+-------------+---------------------------+
¶ Serviço Dinâmico (C#):
public class ValidationService
{
private readonly DbContext _context;
public ValidationService(DbContext context)
{
_context = context;
}
public async Task<bool> ValidateFieldAsync(string tableName, string fieldName, object value)
{
var rule = await _context.Set<SysValidacao>()
.FirstOrDefaultAsync(v => v.TableName == tableName && v.FieldName == fieldName);
if (rule == null) return true;
if (rule.Regra.Contains("NOT NULL") && value == null)
return false;
if (rule.Regra.Contains("MAX") && value is string str && str.Length > rule.MaxValue)
return false;
return true;
}
}
| Última Atualização | Responsável | Status |
|---|---|---|
| 16 de dezembro de 2024 | Márcio de Matos Costa | Abordagem de Validações |
| 10 de dezembro de 2024 | Márcio de Matos Costa | Atualização de SYS_BDA e SYS_BDG (determina hierarquia entre Tabelas, Campos, grupos de guias e campos, guias e campos) |
| 01 de dezembro de 2024 | Márcio de Matos Costa | Atualização de SYS_BDC (Campos do Sistema incluindo campos virtuais, sources de dados e consultas dinamica e compilada. |