"Herdar" sites ASP.NET MVC de um aplicativo de modelo comum? (múltiplos inquilinos)

votos
13

Estamos construindo cerca de 10 sites ASP.NET MVC que têm um conjunto comum de recursos (e URLs correspondentes, rotas Controllers, Ações e Visualizações). Os sites também todos compartilham um conjunto básico de objetos de domínio (por exemplo, usuários, empresas) e atributos de base nesses objetos (por exemplo, nome, endereço, etc.).

Mas cada site também será altamente personalizado e estendido a partir da base. Por exemplo, o nosso site para grandes empresas, públicas terão Subsidiária e campos da Symbol no objeto de domínio da empresa, enquanto o nosso site para startups terão uma empresa de risco e e Financiamento atributos. Olhar e sentir também irá variar consideravelmente, embora nós estamos tentando manter HTML tão consistente como possíveis (módulo extras campos do formulário para atributos extras objeto de domínio, etc). Também estará substituindo imagens com moderação, para que possamos, por exemplo, re-utilizar os mesmos gráficos de botão em sites.

De qualquer forma, nós estamos tentando descobrir a melhor forma de levar e coisas arquiteto para que possamos reutilizar o máximo de código e tantos testes quanto possível sem limitar nossa liberdade para adicionar atributos por app e variar a UI entre aplicativos.

Eu estou familiarizado com a forma de lidar com limitada personalização multi-tenancy como você encontrar em StackOverflow / SuperUser / ServerFault (ou MSDN / TechNet para que o assunto), onde a interface é um pouco diferente eo modelo de dados é mais ou menos idêntico. Mas quando os modelos e UI são muito diferentes (mas herdar de uma base comum), eu sou menos certeza de como proceder.

Estou menos preocupado com questões operacionais, uma vez que provavelmente vai estar executando cada site em um appdomain separado e hospedagem-los em bases de dados separadas. Estou mais preocupado com a redução dos custos de manutenção de código longo prazo, aumentando a agilidade (eg fácil adicionar novos recursos para a base sem quebrar aplicativos derivados), e percebendo poupança dev- / teste de custo de curto prazo, como vamos construir o nosso 2º, 3ª local, 4ª, etc..

Eu estou olhando tanto para a orientação de alto nível e sugestões, mas também sugestões concretas de como fazer essa orientação real usando práticas modernas ASP.NET MVC.

Sei que esta é uma pergunta muito geral, mas para começar eu estou procurando tanto a orientação de alto nível, bem como de concreto pontas-n-truques de como aplicar essa orientação com ASP.NET MVC, incluindo coisas como:

  • recomendações onde dividir base / derivados em projetos do Visual Studio
  • dicas de controle de origem para evitar bifurcação
  • dicas de esquema de banco de dados (FWIW, nossas bases de dados são todos small-- sob 10K linhas por tabela, assim que o custo dev / teste é mais um problema do que DB perf)
  • dicas sobre re-usando controladores / views / etc. correspondente ao modelo base atributos, especialmente re-usando interface do usuário para coisas como formas novo cliente, que terá uma mistura de base e atributos derivados.

Alguém tem um bom conselho para saber como arquiteto de um aplicativo multi-tenant como este?

Publicado 30/09/2009 em 03:28
fonte usuário
Em outras línguas...                            


4 respostas

votos
11

Aqui está o que fazer, e ele funciona muito bem para cerca de 8 locais atualmente.

  • Definir um projeto do núcleo MVC para os controladores, ViewModels, HttpApplication, rotas, etc Isto irá compilar em uma DLL e comprometer a maior parte do seu site.

  • Criar um conjunto básico de exibições padrão, scripts, imagens, etc para o seu site. Estes servidor vontade como padrão para seus sites individuais.

  • Por cliente, criar quaisquer controladores personalizados, rotas, etc que você precisa em um projeto que compila para outro dll.

  • Também por cliente, recriar quaisquer pontos de vista, scripts, imagens que você deseja usar.

Para fazer os passos acima trabalhar juntos, você precisará escrever um pouco de cola. O primeiro pedaço de cola é um mecanismo de exibição personalizado. Você vai querer personalizar o mecanismo de exibição padrão para primeiro olhar para vistas em sua pasta específica do cliente, e, em seguida, a pasta padrão. Isso permite que você facilmente substituir o layout padrão por cliente.

O segundo método de obter tudo funcionando é ter carregar seu aplicativo principal de rotas, controladores, etc do seu conjunto específico de clientes. Para fazer isso eu uso o Managed Extensibility Framework (MEF) para expor um único método Register. Chamar esse método no meu código de montagem cliente registra as rotas e quaisquer outras necessidades específicas do cliente.

Aqui está uma visão geral do que minha estrutura pasta do site parece, com SiteContent sendo verificado para vistas primeiros:

  - AppContent
  - AppContent/Static
  - AppContent/Static/Images
  - AppContent/Static/Scripts
  - AppContent/Static/Styles
  - AppContent/Views
  - AppContent/Views/Shared

  - SiteContent
  - SiteContent/Static
  - SiteContent/Static/Images
  - SiteContent/Static/Scripts
  - SiteContent/Static/Styles
  - SiteContent/Views
  - SiteContent/Views/Shared

  - web.config
  - Global.asax

Eu tenho ajudantes que eu possa usar como SiteImage e AppImage para uso em meus pontos de vista. Além disso, eu faço cada um dos meus sites de cliente usar certos nomes específicos para as suas páginas mestras, que eu não nunca definir em meus padrões AppContent.

Sei que esta é uma visão geral, mas está funcionando bem o suficiente para nós agora.

Respondeu 10/05/2010 em 19:30
fonte usuário

votos
2

Estou envolvido em um tipo similar de "suite" de projetos atualmente que é focada em permitir que os clientes para aplicar para produtos on-line, mas têm requisitos muito semelhantes para o que informação a recolher, onde as únicas diferenças são em torno do produto informações específicas ou ligeiramente diferentes requisitos legislativos.

Uma coisa que temos tentado fazer é criar páginas (modelo, vista e combinações de controladores) que são reutilizáveis ​​em si mesmos, de modo que qualquer aplicativo pode usar a página para capturar informação, mas redirecionar para a próxima página que pode ser diferente, dependendo do tipo de produto está a ser aplicada para. Para conseguir isso estamos usando controladores de base abstratas na forma do padrão método modelo que contêm basicamente toda a lógica do controlador necessário (incluindo métodos de ação com seus filtros de ação aplicados), mas, em seguida, usar métodos abstratos de fazer o material específico, como o redirecionamento para o página seguinte no processo. Isto significa que a aplicação concreta do controlador usado por fluxos de página de aplicação específicos podem conter apenas um método que retorna uma RedirectToActionResult correspondente à página seguinte do fluxo.

Há também objetos de modelo de base que contém funcionalidade comum, seja lógica de validação ou lógica de persistência estado.

Os dados capturados durante o processo de aplicação é mantido no banco de dados como XML objetos de modelo serializado que pode então ser puxado para fora e de-serializado uma vez que o aplicativo é concluído e cuspiu em qualquer formato para qualquer sistema o uso pessoal de operações de back-end para processar aplicações.

As implicações disso é que temos uma estrutura de projeto que consiste em uma dll base que contém classes de nível superior abstratas, interfaces e classes de serviços públicos, bem como ajudantes html, filtros de ação etc. Então nós temos projetos MVC que contêm as implementações concretas da controladores de base, modelos etc, bem como os pontos de vista e masterpages.

A coisa mais difícil é compartilhar pontos de vista e eu não acho que temos adequadamente tenho esse ainda classificado. Embora com MVC 2.0 contendo Áreas Acho que isso vai tornar-se menos de um problema, mas eu não tive um bom jogo com ele ainda. (Ver post do Scott Gu em 2.0:http://weblogs.asp.net/scottgu/archive/2009/07/31/asp-net-mvc-v2-preview-1-released.aspx ) Uma coisa que eu POCed que parece que vai funcionar é usando um projeto base MVC para conter pontos de vista comuns e, em seguida, estendendo-se o mecanismo de exibição padrão para procurar esse projeto no servidor web quando se olha para um fim de render (que é bastante fácil de fazer). Áreas que é uma solução muito mais agradável.

Como para controle de origem, estamos usando svn e eu acho que você é razoável em estar preocupado com ramos. Não é algo que tivemos de lidar com ainda, mas nós provavelmente está indo para ir com git como parece fazer o processo de ramificação e mesclagem muito menos doloroso.

Não tenho certeza se isso ajuda muito, mas eu recomendaria definitivamente manter em controladores e modelos abstratos mente, e também olhar para como você pode usar ajudantes HTML e e vista parcial para agrupar peças semelhantes de funcionalidade.

Respondeu 30/09/2009 em 12:04
fonte usuário

votos
1

Uma maneira de fazer isso é usar ramificação em um sistema de controle de origem.

O ramo principal é para a funcionalidade comum. Você então tem uma filial para personalização e pode mesclar as alterações para o personalização ou volta para o ramo principal.

Respondeu 30/10/2009 em 22:44
fonte usuário

votos
1

Mike Hadlow entra em boa detalhes sobre como fazer isso:

http://mikehadlow.blogspot.com/2008/11/multi-tenancy-part-1-strategy.html

Respondeu 30/09/2009 em 04:45
fonte usuário

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