COMO TRABALHAR COM MULTI EMPRESAS

F001E 15/07/2015 08:56:00
#448853
Bom dia a todos.

Tenho um sistema de Escrituração Fiscal em VB6 que é multi empresa. O usuário faz o login e depois disso escolhe em qual empresa deseja trabalhar. Quando seleciona a empresa o seu código fica armazenado em uma variável pública declarada em um módulo, 
Dim Empresa as string
, onde é usado no projeto todo para gravar o código da empresa nas tabelas por exemplo tabela de produtos onde os mesmo são separados por empresa.
Agora estou com a ideia de passar tudo isso para C# mas em ASP.NET. Como ficaria a questão da empresa escolhida ? Armazeno seu código em uma 
ViewState[[Ô]Empresa[Ô]]
ou em um objeto Session como exemplo abaixo.

public Empresa ObjEmpresa
        {
            get { return (Empresa)Session[[Ô]ObjEmpresa[Ô]]; }
            set { Session[[Ô]ObjEmpresa[Ô]] = value; }
        }


Sendo que o objeto Session terá que ser instanciado em cada WebForm.
ASHKATCHUP 15/07/2015 09:17:59
#448854
Acho melhor usar o ViewStatepor causa do timeout da Session.

http://www.linhadecodigo.com.br/artigo/2360/session-viewstate-ou-cache-o-que-utilizar.aspx
F001E 15/07/2015 09:30:28
#448856
....é... pensei aqui e acho melhor ViewState. A Session por default tem 20 minutos antes do timeout mas dá para aumentar esse tempo só que eu não confio muito nesse tempo.....parece que os minutos da Session tem 30 segundos e não 60 segundos....huahuahua
PROFESSOR 15/07/2015 12:08:34
#448871
O ASP.Net hoje está usando o Asp.Net Identity, e antes usava o Membership Provider, agora considerado [Ô]antigo[Ô].
No Membership Provider há uma tabela chamada [Ô]aspnet_Applications[Ô], que permite que diversos sites usem simultaneamente o mesmo banco de dados, [Ô]separando[Ô] os registros que pertencem a cada site.
Basicamente é a mesma idéia que a sua, ou seja, todas as demais tabelas deverão ter esse campo, de forma que os registros de cada empresa possam coexistir na mesma base de dados.
Infelizmente, não existe um provedor nativo para gerenciar a [Ô]aspnet_Applications[Ô], mas você sempre poderá implementar algo como um Application Provider, se tiver tempo e paciência para entender o funcionamento dos Custom Providers.
De pronto eu não tenho nada em mãos nesse sentido, mas para se aprofundar, você deve buscar na Web por [Ô]Custom Membership Provider[Ô], [Ô]Custom Session Provider[Ô], [Ô]Custom Profile Provider[Ô], [Ô]Custom Role Provider[Ô] e similares.
F001E 15/07/2015 14:12:06
#448887
Citação:

Basicamente é a mesma idéia que a sua, ou seja, todas as demais tabelas deverão ter esse campo, de forma que os registros de cada empresa possam coexistir na mesma base de dados.



Sim PROFESSOR as demais tabelas tem esse campo empresa. Na verdade a base de dados esta pronta mas vou normalizar essa base pois esta confusa, exemplo a tabela de Produtos tem o campo ID_PRODUTO a tabela de produto da NFE tem ID_PRODUTO_NFE e ID_COD_PRODUTO que esse é FK de ID_PRODUTO. Quem olha de primeira não sabe de onde vem isso.

A minha dúvida mesmo é como armazenar o código da Empresa quando o usuário escolher a Empresa para trabalhar. Vou fazer um teste com VIEWSTATE e analisar esse Custom Membership Provider que você mencionou.
KERPLUNK 15/07/2015 18:44:16
#448896 Resposta escolhida
F001E, como o PROFESSOR disse, Membership Provider está defasado e o que está substituindo é o Identity. A minha sugestão é nem mesmo usar o ASP.NET, mas sim uma WebAPI e login baseado em Token. Com ele, você identifica o usuário que ao entrar especifíca a empresa que está usando, para cada ação dele, via AJAX, o nome do ticket do usuário logado é recebido, permitindo assim identificar a empresa que o mesmo está usando. Isso é vantajoso porque tanto o ViewState quanto a Session são objetos que ficam no client, já o token fica no server, facilitando muito sua vida.
F001E 15/07/2015 22:52:58
#448906
KERPLUNK já vi vários posts seu que você defende WebAPI mas eu não sei como usar isso. Teria alguma sugestão de fórum bom que fale e demonstre o uso do WebAPI. Qual ferramenta é utilizada para tal ?
KERPLUNK 16/07/2015 01:40:10
#448910
Aqui vai um exemplo. Usando nada mais que HTML+JQuery(Javascript)+CSS(MetroUI), fiz um exemplo que consome a WebAPI do mercado livre. Ela faz busca de produtos e clicando na foto do produto no resultado da busca, ela ainda exibe um carrossel com as fotos do produto e perguntas e respostas. Em menos de 100 linhas de código, uma aplicação consumindo uma WebAPI, sem uso de nenhuma linguagem server, como PHP, ASP, ASP.NET Ruby ou nada disso, puro HTML, leve simples e 100% adaptável. Se quiser, posso adaptar esse mesmo exemplo também usando AngularJS, o que faria a aplicação ficar ainda mais elegante e funcional.
F001E 16/07/2015 08:43:53
#448915
Citação:

Aqui vai um exemplo. Usando nada mais que HTML+JQuery(Javascript)+CSS(MetroUI), fiz um exemplo que consome a WebAPI do mercado livre. Ela faz busca de produtos e clicando na foto do produto no resultado da busca, ela ainda exibe um carrossel com as fotos do produto e perguntas e respostas. Em menos de 100 linhas de código, uma aplicação consumindo uma WebAPI, sem uso de nenhuma linguagem server, como PHP, ASP, ASP.NET Ruby ou nada disso, puro HTML, leve simples e 100% adaptável. Se quiser, posso adaptar esse mesmo exemplo também usando AngularJS, o que faria a aplicação ficar ainda mais elegante e funcional.



Entendi, vou ver esse exemplo.....
F001E 16/07/2015 10:18:35
#448924
KERPLUNK, e para acessar banco de dados ? Como ficaria !!!
KERPLUNK 16/07/2015 18:00:44
#448937
Citação:

:
KERPLUNK, e para acessar banco de dados ? Como ficaria !!!


Esse é o maior barato da WebAPI, você já está acessando o banco de dados e não só acessando tabelas, você pode liberar acesso ao que você quiser. No exemplo que postei, tem chamada à ela para três rotas: Pesquisa produtos por valor, pesquisa produto por ID de produto e pesquisa dos comentários. Com WebAPI, você faz rotas dando acesso ao que você quiser. Se quiser que tenha acesso para cada tabela, você cria rotas para cada uma delas. Por exemplo, suponha que você tenha uma WebAPI que tenha um cadastro de produtos, como é o caso do mercado livre. Você faria as rotas necessárias para toda e qualquer pesquisa dele:
http://www.minhaaplicacao.com.br/api/produto/12345 - Traz os dados do produto de código [Ô]12345[Ô]
http://www.minhaaplicacao.com.br/api/produto/tipo/roupas - Traz todos os produtos em que o tipo seja [Ô]roupas[Ô]
http://www.minhaaplicacao.com.br/api/produto/02-03-2015/05-06-2015 - Traz todos os produtos que tenham sido cadastrados entre o período

Todas essas rotas podem ter ainda uma sintaxe diferente:
http://www.minhaaplicacao.com.br/api/produto/procura?codProduto=12345
http://www.minhaaplicacao.com.br/api/produto/procura?tipo=roupas
http://www.minhaaplicacao.com.br/api/produto/procura?dtInicial=02-03-2015&dtFinal=05-06-2015

Essas rotas são determinantes de tipo de objeto que você está buscando. Elas também servem para outras funções, de acordo com o verbo HTTP usado. Você pode até mesmo usar verbos personalizados, mas é meio incomum isso. O mais comum são os verbos [Ô]GET, POST, PUT e DELETE[Ô], eles cobre todas as funcionalidades de um CRUD, que são Create, Read, Update e Delete, ou em português Criar, Ler, Atualizar e Deletar.

Para entender cada um desses métodos, vamos usar o próprio site do VBMania como exemplo, que de uma maneira ou de outra usa isso. Quando você digita o endereço www.vbmania.com.br, você está fazendo uma chamada GET ao servidor, que retorna os HTML já processados. Esse é um detalhe importante para se entender em programação web, mas é assunto para um outro tópico. Continuando, essa chamada GET, vai trazer o HTML, CSS e Javascript que serão interpretados pelo seu browser. Com uma WebAPI, é praticamente a mesma coisa, a diferença é que ao invés de um texto HTML, ela vai trazer dados, seja em formato JSON ou XML, quem desenvolve a WebAPI que determina, apesar de ser possível retornar tanto um quanto outro. Quando eu digitei essa resposta na caixa de texto, eu estou usando um método POST para enviar todo este texto para um script PHP que o processa e grava no banco de dados. Com WebAPI, é a mesma coisa, a diferença é que o cliente(sua aplicação que consome a WebAPI) é quem forma o pacote e envia para a rota correspondente, novamente o formato é indiferente, tanto JSON quanto XML, ou ambos. E dessa maneira também para um método PUT que seria [Ô]Editar[Ô] essa resposta. E apesar de não termos essa opção aqui no VBMania, também é possível usar um método [Ô]DELETE[Ô] para apagar uma resposta, ou deletar algum registro do banco.

O caso é que o acesso direto ao banco de dados não existe, ele se dá através de métodos criados na WebAPI. A primeira vista isso pode parecer muito ruim e trabalhoso. Bem, vamos ver as desvantagens disso em relação à um acesso direto ao banco:
- Você fica preso ao que a WebAPI disponibilizar, se quiser fazer uma query um pouquinho diferente e a WebAPI não tem o método correspondente, não tem como
- Por ser essencialmente HTTP, todos os dados, tanto indo quanto vindo para a WebAPI, são sempre em formato texto, JSON ou XML, por isso a aplicação cliente deve ser um mínimo organizada no modelo OOP

Essas são as desvantagens que consigo pensar agora. Mas vamos as vantagens:
- Você pode usar uma mesma base dados para qualquer plataforma, ou seja, você faz a sua WebAPI e pode usar os dados seja de um Tablet, página Web, aplicação desktop, qualquer uma delas vai ter acesso aos mesmos dados
- Você pode liberar acesso à integração com seu banco de dados para qualquer um. Por exemplo, seu cliente comprou sua solução [Ô]WebAPI + aplicação cliente[Ô], ele é uma loja de ferragens e o fornecedor dele gostaria de fazer integração do sistema dele com o de seu cliente. Basta você liberar uma senha de acesso ao fornecedor do seu cliente(ou mesmo seu cliente fazer isso) e pronto, as dias aplicações, a do seu cliente e de seu respectivo fornecedor, tem integração.
- Uma mesma WebAPI, pode servir tanto para o CRUD da aplicação client, quanto para uma loja online. Ou seja, pedidos de venda feitos na loja online caem direto na tela do seu cliente, pagamentos feitos via banco ou paypal, caem direto no fluxo de caixa e assim por diante
- Por ser compatível com qualquer plataforma, você pode dar acesso de dados para outras aplicações. Por exemplo, alguém quer fazer um buscador de preços, e seu cliente, a lojinha de ferragens, quer que seus produtos sejam também pesquisados. Basta passar a URL(rota) que o buscador de preços deve usar e pronto

Tem mais vantagens, mas são mais técnicas:
- Como qualquer plataforma pode integrar com WebAPI, o consumo dos dados pode se dar através de qualquer linguagem, vide o exemplo que passei em HTML consumindo o mercado livre. Ou seja, você não precisa nem mesmo [Ô]hospedar[Ô] uma aplicação web, apenas ter a WebAPI hospedada em algum lugar
- O uso de OOP é primordial para se ter uma WebAPI eficiente e rápida. Por isso, a qualidade técnica do seu código deve ser no mínimo razoável. Até é possível de se usar algo menos tecnicamente correto, mas o desempenho e facilidade de manutenção serão afetados.
- A segurança dos seus dados estará altíssima, pois sem o acesso direto ao banco, todo e qualquer tipo de injeção de código ou dados é muito reduzida.
- Mais uma vez, por ser independente de plataforma, você pode oferecer para seu cliente uma solução mais completa, com uma aplicação desktop, uma web e uma mobile e ele vai ter acesso aos dados dele seja do tablet, celular, computador com ou sem sistema instalado. E lógico, isso custa mais caro.. hehehe


Espero ter ajudado a entender melhor. Mas para reforçar, veja à sua volta, todas as grandes, pequenas e médias empresas da internet oferecem um serviço de integração WebAPI, Google, Facebook, Twitter, MercadoLivre, Buscapé, praticamente todos os bancos, E-Bay, PayPal, Operadoras de celular, operadoras de cartão de crédito, varejistas e atacadistas, enfim, a lista é enorme.

PS: O VBMania tem sim a opção de exclusão de respostas...
Página 1 de 2 [12 registro(s)]
Tópico encerrado , respostas não são mais permitidas
Voltar