Três maneiras diferentes de considerar as opções de design para os suplementos do SharePoint
Pré-requisito: primeiro você deve estar familiarizado com o artigo Suplementos do SharePoint.
Este artigo analisa as opções de arquitetura para suplementos do SharePoint de três maneiras diferentes. Primeiro, você aprenderá sobre as categorias mais importantes de opções de design; segundo, você exibe a arquitetura de suplemento em termos de camadas de aplicativo; e, em terceiro lugar, você vê um conjunto de fatores que você precisa considerar ao fazer suas escolhas de design.
A primeira decisão a tomar é se sua extensão do SharePoint deve ser um Suplemento do SharePoint ou uma solução de farm clássico do SharePoint ou uma solução sandboxed. Algumas partes do modelo de objeto do SharePoint, principalmente conectadas à personalização da administração e segurança do SharePoint, não estão acessíveis de clientes. Somente o código personalizado em execução no servidor do SharePoint pode acessá-los e o código personalizado do lado do servidor não é permitido em um Suplemento do SharePoint. (Um conjunto avançado de modelos de objeto cliente e um serviço REST/OData permitem que os Suplementos do SharePoint façam quase qualquer extensão do SharePoint orientada ao usuário final.)
Para obter mais informações sobre como decidir entre soluções clássicas e suplementos, confira Suplementos do SharePoint em comparação com soluções do SharePoint. Também útil para tomar essa decisão é Escolher o conjunto de API certo no SharePoint.
Elementos-chave no design de suplementos do SharePoint
Três categorias principais de opções precisam ser feitas quando um Suplemento do SharePoint é projetado. Como sempre, o design do aplicativo envolve compensações; as opções que você faz em uma categoria podem limitar suas opções em outra. Nem toda combinação possível de opções é viável.
De: Os suplementos do SharePoint podem ser divididos em dois tipos principais com base em como eles são implantados e hospedados.
Os suplementos hospedados pelo provedor têm o armazenamento de dados primário e a lógica de negócios implantados e hospedados por você, o desenvolvedor, fora do SharePoint em servidores ou uma conta de nuvem que você fornece. Você é responsável por impor o isolamento entre as contas dos vários clientes que compram seu suplemento. Esses suplementos também podem ter componentes do SharePoint. Elas estão hospedadas no farm do SharePoint do cliente. Esse tipo de suplemento oferece mais flexibilidade nas outras categorias de opções de design. Ele também permite que você use plataformas que não são da Microsoft para os dados externos, a lógica e a interface do usuário da Web (interface do usuário). (Dentro da categoria de suplementos hospedados pelo provedor, você também precisa distinguir entre suplementos cujos componentes remotos estão dentro do mesmo firewall corporativo que o farm do SharePoint e aqueles cujos componentes remotos estão fora desse firewall. Os sistemas de autorização para esses dois cenários são diferentes, o que, por sua vez, faz a diferença em qual linguagem de programação você usa para acessar os dados do SharePoint.)
Os suplementos hospedados pelo SharePoint consistem inteiramente em componentes do SharePoint, como listas, tipos de conteúdo, fluxos de trabalho e web parts. Não há componentes externos. Para obter mais informações sobre os tipos de componentes do SharePoint que podem ser incluídos nos Suplementos do SharePoint, consulte Webs host, Webs de suplemento e componentes do SharePoint no SharePoint.
Para obter informações mais detalhadas sobre as opções de hospedagem dos Suplementos do SharePoint, confira Escolher padrões para desenvolver e hospedar seu Suplemento do SharePoint.
Conectividade: O SharePoint dá suporte a três tipos de acesso crud (criar/ler/atualizar/excluir) seguro aos dados.
Aplicativos Web externos em um suplemento usam o protocolo OAuth para acessar dados do SharePoint. Para obter mais informações, consulte Autorização e autenticação de suplementos do SharePoint.
O JavaScript pode acessar dados em um suplemento do SharePoint web e dados em outros sites dentro da mesma locação usando uma biblioteca JavaScript especial que permite scripts entre domínios seguros. Para saber mais, confira Acessar dados do SharePoint a partir de suplementos usando a biblioteca de domínio cruzado.
Um Suplemento do SharePoint também pode acessar dados externos por meio do BCS (Business Connectivity Services) ou de um proxy de serviço Web. Para obter mais informações, consulte Serviços de Conectividade Empresarial no SharePoint e Consultar um serviço remoto usando o proxy Web no SharePoint.
Para obter mais informações sobre armazenamento e acesso de dados em suplementos do SharePoint, confira Armazenamento de dados em Suplementos do SharePoint, Acesso seguro a dados e modelos de objeto cliente para suplementos do SharePoint e Trabalhar com dados externos no SharePoint.
UI: Há três maneiras de criar um Suplemento do SharePoint no SharePoint: no mínimo, todos os suplementos são exibidos em uma página da Web completa. Opcionalmente, um suplemento também pode ser exibido por meio de uma parte do suplemento e por meio de um item de menu ou botão de faixa de opções. Para obter mais informações, confira Design de UX para suplementos do SharePoint.
Observação
Os suplementos do SharePoint podem ser instalados por seus clientes em várias coleções de sites em um aluguel ou em uma base site por site. Os primeiros são chamados de suplementos com escopo de locatário. Se você quiser que seus clientes tenham a opção com escopo de locatário, talvez você não inclua um botão de faixa de opções personalizado ou uma parte de suplemento. Para obter mais informações, confira Locações e escopos de implantação para Suplementos do SharePoint.
Camadas arquitetônicas
Outra maneira de pensar em suas opções de arquitetura de suplemento é pensar no suplemento como tendo três camadas lógicas: a interface do usuário, a lógica de negócios e o acesso a dados. Cada camada tem várias opções de implementação; novamente, as opções feitas para uma camada limitam as opções para outras. As tabelas a seguir descrevem algumas das opções e seus usos para os componentes remotos de um suplemento e os componentes do SharePoint.
Componentes remotos em suplementos hospedados pelo provedor: opções para cada camada
| Camada | Options | Bom para |
|---|---|---|
| Interface do Usuário | ASP.NET páginas em um formulário ASP.NET ou aplicativo MVC hospedado em uma função Web do Azure | Aproveitando as habilidades de uma equipe de desenvolvimento ASP.NET |
| Página HTML 5 com JavaScript | Interface do usuário avançada | |
| PHP ou outro tipo de página da Web hospedada em um serviço de nuvem que não é da Microsoft | Integrando aplicativos que não são da Microsoft ao SharePoint | |
| Silverlight em um aplicativo Windows Phone | Acesso móvel a dados do SharePoint e integração com dados de geolocalização e notificações por push | |
| Lógica comercial | JavaScript do lado do cliente | Lógica da interface do usuário e lógica de negócios leve; acessando dados do SharePoint por meio do modelo de objeto cliente JavaScript |
| Uma função de trabalho do Microsoft Azure | Funcionalidade intensiva em processador; acessando dados do SharePoint por meio do modelo de objeto cliente .NET Framework | |
| Um serviço Web remoto | Funcionalidade intensiva em processador; acessando dados do SharePoint por meio do modelo de objeto cliente .NET Framework | |
| Dados | SQL Azure | Dados relacionais em destaque completos |
| Armazenamento de Tabelas do Azure | Configurações de aplicativo e outros metadados | |
| Armazenamento de Blobs do Azure | Armazenamento de arquivos grandes | |
| Um serviço de nuvem que não seja da Microsoft | Aproveitar as fontes de dados existentes baseadas em plataformas que não são da Microsoft | |
| Um banco de dados no próprio servidor do desenvolvedor | Hospedagem de provedor e controle do desenvolvedor do isolamento de locação |
Componentes do SharePoint: opções para cada camada
| Camada | Options | Bom para |
|---|---|---|
| Interface do Usuário | Exibições personalizadas de listas e bibliotecas do SharePoint em páginas da Web de suplemento | Maximizando a integração com a aparência e o comportamento do SharePoint |
| Aplicativo Silverlight hospedado em uma Web Part (ou dentro <de marcas de objeto> ) em uma página da Web de suplemento | Aproveitando a experiência de desenvolvimento do Silverlight existente; interface do usuário avançada | |
| Lógica comercial | Um fluxo de trabalho do SharePoint | Implementando processos empresariais |
| JavaScript do lado do cliente complementado com a biblioteca de domínio cruzado do SharePoint | Acessando dados do SharePoint na Web de suplemento; acessando dados em outros sites dentro do locatário | |
| Um manipulador de eventos remoto | Manipulação de eventos CRUD em listas e bibliotecas do SharePoint usando lógica hospedada externamente | |
| Dados | Listas e bibliotecas do SharePoint que são consultadas por meio da CAML (Linguagem colaborativa de marcação de aplicativo) ou consultas LINQ com um dos modelos de objeto cliente do SharePoint | Aproveitando a experiência de desenvolvimento do SharePoint e .NET Framework existente |
| Listas e bibliotecas do SharePoint que são consultadas por meio do serviço Web REST/OData do SharePoint | Acessando dados do SharePoint de plataformas que não são da Microsoft; aproveitando a experiência de consulta OData existente | |
| Um modelo BCS | Acessar dados externos no SharePoint como uma lista do SharePoint |
Fatores a serem considerados ao tomar suas decisões de design
O modelo de suplemento do SharePoint permite tantas possibilidades de design que uma árvore de decisão simples não é possível. A seguir estão alguns dos fatores mais importantes a serem considerados ao construir a arquitetura de um Suplemento do SharePoint.
O mais importante, é claro, é a funcionalidade que você deseja disponibilizar aos clientes: os casos de uso. Por exemplo, se o suplemento incluir funções intensivas em processador, como converter arquivos de vídeo em outro formato de vídeo, isso seria um argumento para criar um suplemento hospedado pelo provedor no qual o processamento é feito em um de seus servidores ou em uma função de trabalho do Azure.
Como um tipo de Suplemento do SharePoint, suplementos hospedados pelo provedor, exige que você (ou seu cliente) hospede os componentes que não são do SharePoint e imponha o isolamento do locatário, você precisa considerar se você tem o hardware e a equipe de TI para fazer isso (ou se seus clientes de destino o fazem).
Quais clientes você está direcionando também é uma consideração crucial. Se todos os suplementos forem usados internamente (ou seja, você não tem clientes externos) ou usados por um único cliente, os suplementos hospedados pelo provedor serão significativamente mais fáceis de implementar e manter do que quando você tem clientes externos ou vários clientes usarão o suplemento. Se você pretende vender o suplemento publicamente, também deve considerar se o comercializará para empresas que têm contas do SharePoint Online ou aquelas com suas próprias fazendas do SharePoint ou ambas.
Você também deve considerar suas habilidades existentes ou as habilidades de sua equipe de desenvolvimento. Por exemplo, se você for um desenvolvedor de ASP.NET experiente, isso seria um ponto a favor da criação de um aplicativo Web remoto e da criação de dados de lista do SharePoint em uma página ASP.NET. Por outro lado, se você for um desenvolvedor experiente do SharePoint, isso seria um ponto a favor do uso de uma lista e página de site personalizadas do SharePoint, com JavaScript para executar o processamento.