AJUDA COM PROCESSO / MELHOR TÉCNICA
Boa tarde, pessoal
Estou abrindo esse tópico para saber a opinião de vocês a respeito da centralização de informações. Portanto irei explicar o que preciso fazer e você podem dar a opinião.
Bom é o seguinte, tenho aqui na empresa onde trabalho um projeto que preciso desenvolver que é unificar todas as ferramentas / sistemas para absorver um único local de repositório de dados. Então aqui começa a conversa. O repositório de dados deverá ser consumido por três frentes de sistema, web, desktop e mobile.
Dessa maneira teremos uma mesma DW para que o sistema busque essas informações com a melhor performance possÃvel.
Então minha ideia foi a seguinte, criar um web service, mas como sabemos o mesmo está deixando de ser usado, pois a tendencia é utilizar o WebAPI para o desenvolvimento e eu concordo com isso.
Mediante isso ficou claro que desenvolveremos uma aplicação utilizando WebAPI, mas como? Qual seria o melhor conceito? Existe restrições para tanto request que o mesmo terá?
Então é isso que preciso da ajuda de vocês. Como proceder da melhor maneira possÃvel para que a performance do sistema não seja comprometida?
São tantas perguntas, mas eu vou deixar aqui algumas funcionalidades que os sistema fazem.
Tipos de sistema
Web:
Portal institucional (Consultas de dados / Alguns Update/Delete/Insert)
Portal de Relacionamento com Investidor (Consultas de dados / Alguns Update/Delete/Insert)
Gerenciador de conteúdo (Full Select/Insert/Update/Delete)
Desktop:
Sistema Auditoria (Consultas de dados / Alguns Update/Delete/Insert)
Sistema Administrativo (Consultas de dados / Alguns Update/Delete/Insert)
Mobile:
App Cooperado (Consultas de dados)
App Colaborador (Consulta de dados / Alguns Update/Insert/Delete)
Sistema de Terceiro:
Independente Plataforma (Mobile/Web/Desktop):
Esses sistema poderão consumir o mesmo recurso, porem existir funcionalidades que o mesmo não pode enxergar devido ser somente para uso interno da empresa.
Então que vocês possam me ajudar com o conhecimento de vocês, tenho esse desafio e não sei por onde começar a realizar esses afazeres.
Conto com a ajuda de vocês, obrigado.
Estou abrindo esse tópico para saber a opinião de vocês a respeito da centralização de informações. Portanto irei explicar o que preciso fazer e você podem dar a opinião.
Bom é o seguinte, tenho aqui na empresa onde trabalho um projeto que preciso desenvolver que é unificar todas as ferramentas / sistemas para absorver um único local de repositório de dados. Então aqui começa a conversa. O repositório de dados deverá ser consumido por três frentes de sistema, web, desktop e mobile.
Dessa maneira teremos uma mesma DW para que o sistema busque essas informações com a melhor performance possÃvel.
Então minha ideia foi a seguinte, criar um web service, mas como sabemos o mesmo está deixando de ser usado, pois a tendencia é utilizar o WebAPI para o desenvolvimento e eu concordo com isso.
Mediante isso ficou claro que desenvolveremos uma aplicação utilizando WebAPI, mas como? Qual seria o melhor conceito? Existe restrições para tanto request que o mesmo terá?
Então é isso que preciso da ajuda de vocês. Como proceder da melhor maneira possÃvel para que a performance do sistema não seja comprometida?
São tantas perguntas, mas eu vou deixar aqui algumas funcionalidades que os sistema fazem.
Tipos de sistema
Web:
Portal institucional (Consultas de dados / Alguns Update/Delete/Insert)
Portal de Relacionamento com Investidor (Consultas de dados / Alguns Update/Delete/Insert)
Gerenciador de conteúdo (Full Select/Insert/Update/Delete)
Desktop:
Sistema Auditoria (Consultas de dados / Alguns Update/Delete/Insert)
Sistema Administrativo (Consultas de dados / Alguns Update/Delete/Insert)
Mobile:
App Cooperado (Consultas de dados)
App Colaborador (Consulta de dados / Alguns Update/Insert/Delete)
Sistema de Terceiro:
Independente Plataforma (Mobile/Web/Desktop):
Esses sistema poderão consumir o mesmo recurso, porem existir funcionalidades que o mesmo não pode enxergar devido ser somente para uso interno da empresa.
Então que vocês possam me ajudar com o conhecimento de vocês, tenho esse desafio e não sei por onde começar a realizar esses afazeres.
Conto com a ajuda de vocês, obrigado.
O design do seu banco está apropriado? Você usa chaves primárias, estrangeiras, views e stored procedures apropriadamente?
Seu banco de dados é realmente eficiente em termos de performance?
Você tem um hardware também robusto onde seu banco de dados roda?
Com o banco de dados resolvido o próximo passo é escalonamento de camada WebAPI:
Você pretende usar a WebAPI no mesmo local(server) em que seu banco de dados está?
Se não, a rede entre WebAPI e banco de dados está apropriadamente funcional?
A máquina onde a WebAPI roda é robusta?
Só essas coisas já demanda um bocado de trabalho e investimento. Se usar tudo numa máquina só, o que é totalmente possÃvel mas não ideal, você terá que ter uma máquina realmente [Ô]paulada[Ô] para não ter trancos. Banco de dados e WebAPI são o background da coisa toda, com essa parte ok, o desenvolvimento em si não é problema.
Seu banco de dados é realmente eficiente em termos de performance?
Você tem um hardware também robusto onde seu banco de dados roda?
Com o banco de dados resolvido o próximo passo é escalonamento de camada WebAPI:
Você pretende usar a WebAPI no mesmo local(server) em que seu banco de dados está?
Se não, a rede entre WebAPI e banco de dados está apropriadamente funcional?
A máquina onde a WebAPI roda é robusta?
Só essas coisas já demanda um bocado de trabalho e investimento. Se usar tudo numa máquina só, o que é totalmente possÃvel mas não ideal, você terá que ter uma máquina realmente [Ô]paulada[Ô] para não ter trancos. Banco de dados e WebAPI são o background da coisa toda, com essa parte ok, o desenvolvimento em si não é problema.
Olá KERPLUNK, consegui ter uma interatividade com você! rsrsrs
Bom vamos lá
O design do seu banco está apropriado? [txt-color=#007100]Sim[/txt-color]
Você usa chaves primárias, estrangeiras, views e stored procedures apropriadamente? [txt-color=#007100]Sim[/txt-color]
Seu banco de dados é realmente eficiente em termos de performance? [txt-color=#007100]Sim[/txt-color]
Você tem um hardware também robusto onde seu banco de dados roda? [txt-color=#007100]Sim[/txt-color]
Você pretende usar a WebAPI no mesmo local(server) em que seu banco de dados está? [txt-color=#007100]Não, servidores separados.[/txt-color]
Se não, a rede entre WebAPI e banco de dados está apropriadamente funcional? [txt-color=#007100]Sim[/txt-color]
A máquina onde a WebAPI roda é robusta? [txt-color=#007100]Sim. 12gb Ram / 8 nucleos / Windows Server 2012 / IIS 7[/txt-color]
Mas a ideia principal é como proceder com os métodos de chamadas.
Tipo isso vai ser usado para os sistemas internos/externos, porém o cliente externo não pode ver alguns recursos de uso interno.
Como você procederia? Pode me ajudar com isso?
Bom vamos lá
O design do seu banco está apropriado? [txt-color=#007100]Sim[/txt-color]
Você usa chaves primárias, estrangeiras, views e stored procedures apropriadamente? [txt-color=#007100]Sim[/txt-color]
Seu banco de dados é realmente eficiente em termos de performance? [txt-color=#007100]Sim[/txt-color]
Você tem um hardware também robusto onde seu banco de dados roda? [txt-color=#007100]Sim[/txt-color]
Você pretende usar a WebAPI no mesmo local(server) em que seu banco de dados está? [txt-color=#007100]Não, servidores separados.[/txt-color]
Se não, a rede entre WebAPI e banco de dados está apropriadamente funcional? [txt-color=#007100]Sim[/txt-color]
A máquina onde a WebAPI roda é robusta? [txt-color=#007100]Sim. 12gb Ram / 8 nucleos / Windows Server 2012 / IIS 7[/txt-color]
Mas a ideia principal é como proceder com os métodos de chamadas.
Tipo isso vai ser usado para os sistemas internos/externos, porém o cliente externo não pode ver alguns recursos de uso interno.
Como você procederia? Pode me ajudar com isso?
Bem, 12gb de RAM 8 núcleos, é inferior à minha estação de trabalho, mas ok, vai funcionar. O servidor de desenvolvimento que uso tem 64Gb de RAM, 4 processadores i7 de 8 núcleos e ele é só para a aplicação web, o que roda o banco é ainda mais pontente Mas vamos lá:
Você teria basicamente 2 projetos para seu backwork: um contendo a interação com o banco de dados(se possÃvel, usando Entity Framework, mas não é obrigatório) e o outro seria uma WebAPI que consome esse primeiro. No seu projeto de integração com o banco, você pode fazer tudo que quiser, como seria um projeto interno, ele integra diretamente com o banco, não necessitando de uma interface como uma WebAPI. Já o que seus clientes [Ô]veriam[Ô] é uma WebAPI e nela você disponibiliza o que quiser, não necessariamente todas as funcionalidades do projeto de interação com o banco de dados. Esses dois projetos podem ser divididos ainda em outros projetos se quiser, organizando ainda melhor sua estrutura de código. O uso de Stored Procedures, Ãndices e Views também vai ajudar bastante no desempenho, portanto não economize nisso e aplique sempre que possÃvel/necessário. Essa é uma maneira fácil de separar as responsabilidades, mas não ideal.
O fato de o cliente não poder ver alguns recursos, não deveria ser obstáculo. Sua WebAPI, quase que obrigatoriamente irá trabalhar com autenticação de usuário e é aà que você deve limitar o que o cliente pode ou não fazer, com uso de Roles ou qualquer outro controle de responsabilidade de sua preferência. Então a WebAPI seria o único ponto de acesso para todos, clientes internos e externos. Isso, tecnicamente, é um pouco mais [Ô]difÃcil[Ô] de ser feito, mas é a maneira ideal de funcionamento, assim, você centraliza tudo na sua WebAPI que seria a única aplicação à se conectar com o backwork de interação com banco de dados.
Você teria basicamente 2 projetos para seu backwork: um contendo a interação com o banco de dados(se possÃvel, usando Entity Framework, mas não é obrigatório) e o outro seria uma WebAPI que consome esse primeiro. No seu projeto de integração com o banco, você pode fazer tudo que quiser, como seria um projeto interno, ele integra diretamente com o banco, não necessitando de uma interface como uma WebAPI. Já o que seus clientes [Ô]veriam[Ô] é uma WebAPI e nela você disponibiliza o que quiser, não necessariamente todas as funcionalidades do projeto de interação com o banco de dados. Esses dois projetos podem ser divididos ainda em outros projetos se quiser, organizando ainda melhor sua estrutura de código. O uso de Stored Procedures, Ãndices e Views também vai ajudar bastante no desempenho, portanto não economize nisso e aplique sempre que possÃvel/necessário. Essa é uma maneira fácil de separar as responsabilidades, mas não ideal.
O fato de o cliente não poder ver alguns recursos, não deveria ser obstáculo. Sua WebAPI, quase que obrigatoriamente irá trabalhar com autenticação de usuário e é aà que você deve limitar o que o cliente pode ou não fazer, com uso de Roles ou qualquer outro controle de responsabilidade de sua preferência. Então a WebAPI seria o único ponto de acesso para todos, clientes internos e externos. Isso, tecnicamente, é um pouco mais [Ô]difÃcil[Ô] de ser feito, mas é a maneira ideal de funcionamento, assim, você centraliza tudo na sua WebAPI que seria a única aplicação à se conectar com o backwork de interação com banco de dados.
Complementando:
Na WebAPI, estará à disposição de qualquer um, todas as funcionalidades de dados que você deseja, porém o acesso se dá através de permissão ou não. Ou seja, o cliente externo até conseguiria [Ô]chamar[Ô] um método(rota), mas as permissões dele seriam insuficientes e ele receberia um erro [Ô]401 - não autorizado[Ô].
Na WebAPI, estará à disposição de qualquer um, todas as funcionalidades de dados que você deseja, porém o acesso se dá através de permissão ou não. Ou seja, o cliente externo até conseguiria [Ô]chamar[Ô] um método(rota), mas as permissões dele seriam insuficientes e ele receberia um erro [Ô]401 - não autorizado[Ô].
Então, meu servidor de banco é linux da oracle com o banco oracle. O servidor tem espelhamento pra o sistema operacional e 132gb de ram e 4 processador Xeon de 8 nucleos.
Para o servidor de aplicação posso aumentar o recurso sem problema, mas creio que inicialmente deve comportar, pois no inicio vai ser tranquilo.
Quanto a sua visão de como proceder no projeto, não posso utilizar Entity Framework, pois a base de dados que temos aqui é de um sistema de terceiro no qual temos acesso para extração de informações e que também criamos recursos dentro do próprio sistema. Então como as atualizações são constantes seria um trabalho muito intenso para ficar dando manutenção, pois se a tabela sofrer mudança de estrutura vai ferrar tudo e fora a quantidade de dados que o sistema tem isso tornaria o processo lento. (Isso é o meu ponto de vista)
Mas agora ponderando a sua ideia como eu poderia proceder para criar esse projeto backwork?
No recurso de integração com o banco de dados eu faria uma aplicação [Ô]Class Library[Ô] que seria incorporada no meu projeto [Ô]WebAPI[Ô].
Como você procederia para uma conexão robusta com diversos banco de dados? Pois hoje o foco será o Oracle, mas existe os resÃduos que é Firebird e SQL Server
O nosso gerente quer fazer esse repositório para que na hora que precisar fazer manutenção faça somente em um lugar caso seja estrutura vinculada a informações de banco de dados.
Então pensando nisso teremos duas frente principais, portal institucional e WebAPI. Então se eu mudar alguma estrutura de banco e precisar atualizar a aplicação de integração com o banco teria que atualizar as outras duas aplicações, mas como poderia centralizar essa atualização? Existe como isso?
Aguardo uma opinião, pois as suas ideias podem me ajudar muito e as ideias de quem puder opinar.
Obrigado.
Para o servidor de aplicação posso aumentar o recurso sem problema, mas creio que inicialmente deve comportar, pois no inicio vai ser tranquilo.
Quanto a sua visão de como proceder no projeto, não posso utilizar Entity Framework, pois a base de dados que temos aqui é de um sistema de terceiro no qual temos acesso para extração de informações e que também criamos recursos dentro do próprio sistema. Então como as atualizações são constantes seria um trabalho muito intenso para ficar dando manutenção, pois se a tabela sofrer mudança de estrutura vai ferrar tudo e fora a quantidade de dados que o sistema tem isso tornaria o processo lento. (Isso é o meu ponto de vista)
Mas agora ponderando a sua ideia como eu poderia proceder para criar esse projeto backwork?
No recurso de integração com o banco de dados eu faria uma aplicação [Ô]Class Library[Ô] que seria incorporada no meu projeto [Ô]WebAPI[Ô].
Como você procederia para uma conexão robusta com diversos banco de dados? Pois hoje o foco será o Oracle, mas existe os resÃduos que é Firebird e SQL Server
O nosso gerente quer fazer esse repositório para que na hora que precisar fazer manutenção faça somente em um lugar caso seja estrutura vinculada a informações de banco de dados.
Então pensando nisso teremos duas frente principais, portal institucional e WebAPI. Então se eu mudar alguma estrutura de banco e precisar atualizar a aplicação de integração com o banco teria que atualizar as outras duas aplicações, mas como poderia centralizar essa atualização? Existe como isso?
Aguardo uma opinião, pois as suas ideias podem me ajudar muito e as ideias de quem puder opinar.
Obrigado.
Citação:pois a base de dados que temos aqui é de um sistema de terceiro no qual temos acesso para extração de informações e que também criamos recursos dentro do próprio sistema.
Essa parte é que magoa, já trabalhei em projetos similares, e depois de anos tentando, convenci a empresa que se quer ter dominio da base, o sistema deve ser nosso por inteiro e nao terceiro e assim foi importado o conteudo e deu a liberdade que precisavamos para fazer as coisas com o hardware que tinhamos ( e olha que na epoca era 4gb de memoria).
Na minha opiniao voce esta no caminho certo ao usar Oracle (melhor banco que ja trabalhei), o resto é arquitetar mesmo !
Com multiplicidade de bancos a coisa complica um pouquinho. O mais aconselhável nessa situação é o uso do padrão Factory. À primeira vista parece complicado, mas na verdade é bem simples, o caso é que você precisa do domÃnio da OOP, incluindo abstrações(que em essência é o que o padrão factory é). Com ele você pode ter quantos bancos quiser e você trabalha seu Namespace de backwork da maneira que quiser, incluindo usar o mesmo padrão que uso nos meus vÃdeos. A única diferença é que você vai estar usando os objetos da abstração da factory ao invés dos objetos literais do banco de dados especÃfico.
é estou vendo que não vai dar tempo o suficiente pra concluir esse projeto! rsrs
Na vdd eu já trabalho com OOP e abstração creio que não será tão difÃcil, mas a questão é que hoje eu utilizo as bibliotecas nativa do VS System.Data / System.Data.SqlClient / System.Data.OracleCliente
A do oracle já está obsoleta, então pensei que se alguém tiver ideia de recursos mais robusto para fazer a conexão com o banco de dados seria melhor.
WEBMASTER, escreveu:
Realmente isso é complicado, tÃnhamos o sistema desenvolvido internamente, mas a ultima gerencia resolveu terceirizar para diminuir o quadro de funcionários e isso complicou mais.
KERPLUNK, escreveu:
Até já dei uma olhada sobre padrão Factory, mas não cheguei ir a fundo nessa questão até por que não tinha tempo e agora tenho que entender de ultima hora, mas pelo o que eu já vi é baseado em estrutura Entity não é?
Bom seja lá como for, preciso entregar essa estrutura para 31/10 isso é o pior.
Mas voltando ao assunto anterior, o projeto de integração com o banco é uma [Ô]class library[Ô] mesmo e é possÃvel ser consumida de aplicações diferentes sem ter que publicar em lugares diferente?
Na vdd eu já trabalho com OOP e abstração creio que não será tão difÃcil, mas a questão é que hoje eu utilizo as bibliotecas nativa do VS System.Data / System.Data.SqlClient / System.Data.OracleCliente
A do oracle já está obsoleta, então pensei que se alguém tiver ideia de recursos mais robusto para fazer a conexão com o banco de dados seria melhor.
WEBMASTER, escreveu:
Citação:Essa parte é que magoa, já trabalhei em projetos similares, e depois de anos tentando, convenci a empresa que se quer ter dominio da base, o sistema deve ser nosso por inteiro e nao terceiro e assim foi importado o conteudo e deu a liberdade que precisavamos para fazer as coisas com o hardware que tinhamos ( e olha que na epoca era 4gb de memoria).
Na minha opiniao voce esta no caminho certo ao usar Oracle (melhor banco que ja trabalhei), o resto é arquitetar mesmo !
Realmente isso é complicado, tÃnhamos o sistema desenvolvido internamente, mas a ultima gerencia resolveu terceirizar para diminuir o quadro de funcionários e isso complicou mais.
KERPLUNK, escreveu:
Citação:Com multiplicidade de bancos a coisa complica um pouquinho. O mais aconselhável nessa situação é o uso do padrão Factory. À primeira vista parece complicado, mas na verdade é bem simples, o caso é que você precisa do domÃnio da OOP, incluindo abstrações(que em essência é o que o padrão factory é). Com ele você pode ter quantos bancos quiser e você trabalha seu Namespace de backwork da maneira que quiser, incluindo usar o mesmo padrão que uso nos meus vÃdeos. A única diferença é que você vai estar usando os objetos da abstração da factory ao invés dos objetos literais do banco de dados especÃfico.
Até já dei uma olhada sobre padrão Factory, mas não cheguei ir a fundo nessa questão até por que não tinha tempo e agora tenho que entender de ultima hora, mas pelo o que eu já vi é baseado em estrutura Entity não é?
Bom seja lá como for, preciso entregar essa estrutura para 31/10 isso é o pior.
Mas voltando ao assunto anterior, o projeto de integração com o banco é uma [Ô]class library[Ô] mesmo e é possÃvel ser consumida de aplicações diferentes sem ter que publicar em lugares diferente?
Você pode usar modelos T4 para facilitar sua vida. Faça uma classe apenas, com todos os recursos e detalhes que quiser, depois construa um modelo T4 que gera o código para as demais classes(entidades) e corra pro abraço, gerando quantas quiser com apenas um clique, incluindo, se desejar, scaffolding, onde todo o banco de dados pode ser [Ô]revertido[Ô] para as classes do jeito que quiser. Tem vários tutoriais de como fazer isso, como este aqui. Eu uso bastante e sem eles, jamais conseguiria uma produtividade aceitável. Escrever tudo na mão é pra doido. Faça uma vez muito bem feito e use o mesmo modelo para todo o resto e você pode ter vários modelos, de acordo com o que você quer.
Complementando: Com modelos T4, hoje em dia só faço a modelagem do banco, usando Code-First e usando vários modelos T4 gero uma aplicação praticamente completa, usando Angular 4 como UI, uma WebAPI com OData e a DLL que crio contendo o Entity Framework, que é basicamente a única coisa que faço à mão. PouquÃssimas mudanças e somente para coisas mais especÃficas. Tenho modelos para telas Master/Detail, com e sem grids, validações de dados, baseadas no tipo de dados de cada campo e decorações(usando Reflection), por exemplo, campos de e-mail, CNPJ/CPF e coisas do tipo. Rende muito, mas muito mais mesmo. Na real, aplicações simples de cadastros apenas, consigo fazer em coisa de 2-3 horas. O mesmÃssimo pode ser feito para aplicações Desktop também, sem problema algum.
Faça seu login para responder