aplicativo multi inquilino que compartilhar dados (Asp mvc net + Entity Framework + Sql Server)

votos
6

Estou desenvolvendo uma arquitetura de aplicativo inquilino de multi que é bastante complexa.

.

3 tipo completamente diferente de aplicativo

Ther não é apenas um tipo de aplicação utilizada por muitos clientes; o são 3 tipos diferentes de aplicações.

APP A, APP B, C de APP

.

Cada APP é multitenant

Cada aplicativo tem seus clientes.

APP A - cliente A1 - cliente A2

APP B - cliente B1 - B2 cliente

APP C - C1 cliente - C2 cliente

.

INFORMAÇÕES COMUNS

Muitas informações são compartilhadas betwen os diferentes aplicativos

cliente A1 precisa de manipular ou apenas dados de visualização de propriedade de C1 cliente

.

QUESTÃO

Considere que eu estou usando MVC net Asp, EF, Sql Server. Wich é a implementação correta?

Um site e muitas áreas? Criar vários sites? db múltipla? Apenas um db? Filtragem? Sql filtrada vista? ...

Alguns exemplo de aplicação?

EDITAR

e ... Onde colocar a lógica de negócios?

Publicado 12/11/2010 em 11:53
fonte usuário
Em outras línguas...                            


5 respostas

votos
2

Eu recomendaria que você primeiro construir a sua própria pilha de engenharia multi-tenant (Framework) no topo da Net, que irá lidar com todos os requisitos de multilocação em termos de isolamento inquilino dados sábio, suporte para escalonamento horizontal, filtragem de pontos de vista com base na o contexto de arrendatário e do papel do usuário, inquilino sábio extensão modelo de dados, inquilino sábio personalização UI, impondo restrições de acesso com base em funções, privilégios e escopo de dados - que pode ser diferente para diferentes inquilinos etc.

A lógica de negócios pode ser construído em cima deste quadro. Esta abordagem irá fornecer o seu produto de uma fundação de engenharia robusto e forte.

A outra alternativa é comprar um pronto para usar pilha de engenharia multi-tenant da prateleira, instalá-lo no Visual Studio e usá-lo como um modelo de desenvolvimento.

Respondeu 21/01/2011 em 08:02
fonte usuário

votos
0

Minha sugestão é usar PRISM com Sliverlight e MVVM Patten design. Prism é concebido para esse tipo de aplicação, onde cada composto aplicação é independente e também podem comunicar uns com os outros através de eventos expostos por Prism.

Respondeu 20/01/2011 em 10:49
fonte usuário

votos
0

Esta é uma resposta concreta, mas apenas alguns aspectos que você pode considerar ao projetar este.

Com relação às informações compartilhadas, eu acho que a parte mais importante aqui é para definir a relação entre os clientes e os papéis e direitos de cada cliente tem com relação a outros clientes. A melhor abordagem é começar com é identificar o que exatamente pode ser feito.

Exemplo:

Read Only|cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1   | 1   | 0
customer2| 0   | 1   | 0
customer3| 1   | 0   | 1

Write    |cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1   | 1   | 0
customer2| 0   | 1   | 0
customer3| 0   | 0   | 1

Assim, no exemplo acima, cliente1 pode ler e gravar dados (atualização) do customer2.

Dito isto, a questão principal é modelar essas relações, ou seja, as informações compartilhadas. Usando @ sugestão de TFD, essas relações podem ser carregados na sessão para quando um cliente faz logon, juntamente com as relevantes id do inquilino.

(Com base nas informações fornecer, a minha outra inclinação é que este pode ser um por aplicação preocupação e não um cliente única preocupação. Para ilustrar isso, substituir os valores 'cust' nas tabelas acima com App.)

Criar sites separados para cada aplicação desde que eu estou supondo que cada aplicação tem um propósito único, embora não é compartilhada funcionalidade.

Talvez uma diferente configuração DB é necessária se há outras relações de dados transversais. O DB seria armazenar todas as informações inquilino (incl. Relações com outros aplicativos) para cada aplicativo. A razão para esta sugestão é que a partir do que eu posso ver, você tem três aplicativos multi-tenant separados independentes um do outro usando uma abordagem DB compartilhada - mas cada App precisa interagir com um outro App em algum nível.
Em termos de clientes dentro do DB, eu sugeriria então que a tabela de 'clientes' limitar-se à configuração DB. Você pode então ter um conteúdo DB com base em requisitos de cada aplicação.

Respondeu 01/12/2010 em 21:25
fonte usuário

votos
0

Idealmente em um servidor multi-tenant com um único aplicativo que você deseja fisicamente diferentes bases de dados para cada inquilino, ao invés de apenas um especificando coluna que inquilino os dados pertencem também

Mas de qualquer forma, você tem que garantir que TODAS as funções de banco de dados usar a chave de conexão de banco de dados ou coluna inquilino correto. Esse é o real problema

A maneira de se certificar deste é ter apenas UMA função por app que faz esta decisão, e certifique-se todas as funções de banco de dados falhar se eles não têm chamado esta função (direta ou indiretamente, como a seguir)

por exemplo, com MVC no global.asax AuthenticateRequest ou BeginRequest funcionar você pode validar quem é o usuário e, em seguida, calcular qual conexão de banco de dados que eles precisam para usar ou o inquilino coluna de chave que deve usar em cada consulta para esse pedido. Este é então armazenada em uma variável de sessão etc

Se você tem três aplicativos, gostaria de fazer três locais separados. Eles podem compartilhar classes comuns através de um projeto compartilhado. A vida é geralmente mais fácil se eles podem ser implantados separadamente

Respondeu 01/12/2010 em 04:18
fonte usuário

votos
-1

Você pode ter várias abordagens - uma vez que o aplicativo é de dados impulsionada, faz sentido para construir um projeto de banco de dados que protege os dados mesmo em caso de erros de aplicação.

Uma maneira de fazer isso é garantir que existem procedimentos armazenados para acessar as tabelas e a lógica de segurança é integrado pelos procedimentos armazenados. Você pode garantir que um nome de usuário db diferente é usado para cada cliente, e que esse nome de usuário db é mapeado contra esse ID de inquilino em uma tabela de mapeamento. Então, os procedimentos armazenados pode ter sempre uma verificação de que os dados que está sendo solicitado / modificado é realmente pertencentes ao id inquilino mapeado para o usuário db que está executando o proc (usando informações de contexto).

Então você vai precisar de alguma maneira de garantir que a conexão db criado pelo aplicativo usa apenas o nome de usuário correspondente que mapeia para que id inquilino. Isto significa que você precisa de um proc mais armazenado que lhe dá esta informação (provavelmente com nome de usuário / id como a entrada) e este proc armazenado deve ser executável através de um nome de usuário db comum. Lembre-se, este é o único proc armazenado que precisa ter privilégios de execução dadas para este usuário db comum.

Isto pode parecer como escrever um monte de código extra, mas realmente ajuda a saber que o seu db irá rejeitar pedidos ruins até mesmo devido a erros de aplicação. O único lugar que você tem ser muito, muito cuidado é o lugar onde você obtém o nome de usuário inquilino db direita e senha para esse ID de usuário, e que deve ser bastante possível.

Respondeu 03/12/2010 em 05:54
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more