Suplementos do SharePoint em comparação às soluções do SharePoint
Saiba mais sobre quando desenvolver sua extensão SharePoint como um Suplemento do SharePoint, quando desenvolvê-lo como uma solução de farm do SharePoint ou como uma solução de área restrita sem código.
Este artigo compara os casos de uso de Suplementos do SharePoint, soluções de farm e sem código soluçăos em área restrita (NCSSs).
- Novo Suplementos do SharePoint são independentes extensões que podem incluir dados e lógica baseada em nuvem, SharePoint componentes e scripts do lado do cliente, mas não personalizado código gerenciado que é executado em servidores SharePoint. Eles são instalados a partir do Office Store ou um catálogo de suplemento de organização e podem ser instalados em farms local ou Microsoft SharePoint Online. Para obter uma visão geral dos suplementos do SharePoint, consulte Suplementos do SharePoint.
- As soluções de farm do SharePoint são pacotes de componentes do SharePoint que são carregados em uma galeria de todo o farm, de onde eles podem ser instalados. Eles não podem ser distribuídos por meio de Office Store e eles não podem ser instalados em SharePoint Online. Eles podem incluir um código gerenciado personalizado que é executado em servidores do farm SharePoint. Para obter mais informações sobre os conceitos básicos das soluções farm, consulte Visão geral de soluções e soluções de farm no SharePoint 2010.
- NCSSs também são pacotes de componentes de SharePoint; mas, eles são carregados para uma galeria de conjunto de sites de onde eles podem ser instalados. Eles podem ser instalados em qualquer um dos farms locais ou no SharePoint Online, porém não podem ser distribuídos pelo Office Store. Eles podem incluir quase os mesmos tipos de componentes descritivos que suplementos do SharePoint e, como suplementos, podem ter JavaScript, mas não contêm código gerenciado personalizado executado nos servidores do SharePoint. Diferenças nos sistemas de implantação de suplementos e NCSSs Verifique NCSSs a melhor opção de desenvolvimento para uma pequena lista de cenários. Para obter informações sobre soluções sandboxed, consulte Soluções sandboxed no SharePoint 2010.
Importante
Embora ainda seja viável desenvolver soluções de área restrita que contenham apenas marcação declarativa e JavaScript, o que chamamos de soluções de área restrita sem código (NCSS), substituímos o uso de código gerenciado personalizado na solução de área restrita. Apresentamos o novo modelo de Suplemento do SharePoint como um substituto para esses cenários que exigiam o uso de código gerenciado. O modelo de suplemento dissocia o produto principal de SharePoint de tempo de execução add-in, e isso permite muito mais flexibilidade e fornece a capacidade de executar o código no ambiente da sua escolha. Sabemos que nossos clientes investiram em soluções de área restrita codificadas e vamos eliminá-las progressivamente e de forma responsável. As soluções em área restrita codificadas existentes continuarão a funcionar nos farms locais do SharePoint em um futuro próximo. Devido à natureza dinâmica dos serviços online, podemos determinar as necessidades de suporte para codificados soluçăos em área restrita em SharePoint Online com base na demanda dos clientes. NCSSs continuam a ser suportados. Todos os investimentos futuros serão direcionados para tornar o novo modelo de Suplemento do SharePoint mais sofisticado e eficiente. Apropriadamente, recomendamos que todos os de desenvolvimento de novos deve usar o novo suplemento modelo sempre que possível. Em cenários em que é necessário desenvolver uma solução de farm ou uma solução de área restrita codificada, recomendamos que a solução seja projetada para que possa evoluir facilmente em direção a um modelo de desenvolvimento mais flexível.
Desenvolva um suplemento sempre que puder
As orientações mais importantes, que nós podemos lhe é desenvolver um Suplemento do SharePoint em vez de um farm solution ou NCSS sempre que possível. Suplementos do SharePoint têm as seguintes vantagens sobre soluções clássicas:
- Forneça aos usuários com o processo de descoberta, compra e instalação mais fácil.
- Fornecem aos administradores as extensões de SharePoint mais seguras.
- Fornecer a você o mais simples sistema de venda e marketing com base no Microsoft online suplemento store.
- Maximize a sua flexibilidade no desenvolvimento de futuras atualizações.
- Maximize sua capacidade de aproveitar sua existente não -SharePoint habilidades de programação.
- Integre recursos baseados em nuvem de maneiras mais perfeição e mais flexíveis.
- Ative sua extensão tenha permissões que são distintas das permissões do usuário que está executando o add-in.
- Habilite o uso de padrões de plataforma cruzada, incluindo HTML, REST, OData, JavaScript e OAuth.
- Permitem tirar proveito da biblioteca entre domínios JavaScriptSharePoint para acessar dados SharePoint. Como alternativa, você pode usar um fornecida pela Microsoft seguro token serviço que é compatível com o OAuth ou usar certificados digitais para obter autorização aos dados SharePoint.
Suplementos ou NCSSs de design para usuários finais e soluções de farm de design para administradores
Suplementos do SharePoint e NCSSs usar um dos modelos de objeto do cliente SharePoint ou pontos de extremidade do REST para acessar o conteúdo de SharePoint e componentes. Esses clientes APIs habilitar extensões SharePoint projetadas para usuários finais. ("Usuários finais" nesse contexto são administradores de conjunto de sites, proprietários de sites e membros do site.) O modelo de objeto do servidor tem APIs adicionais que permitem programáticas extensões de segurança, configuração e gerenciamento de SharePoint. Eles incluem as extensões de Administração Central, comandos personalizados Windows PowerShell, backups personalizados e trabalhos de timer. Para obter mais informações sobre os tipos de extensões administrativas que você pode desenvolver, consulte Windows SharePoint Services Administração. Essas extensões administrativas são implantados em SharePoint recursos com escopo de conjunto de sites, aplicativo web ou farm. SharePointsoluções de farm também são instalados pelos administradores de farm, embora suplementos e NCSSs podem ser instalados pelos administradores do conjunto de site e de locatário.
O modelo de objeto do servidor também tem APIs para criar, ler, atualizar e excluir operações CRUD () em listas, bibliotecas e sites e para operações em outros componentes de SharePoint. Isso significa que o modelo de objeto do servidor pode ser usado para extensões que servem para usuários finais, mas por motivos de dado na seção anterior, soluções de farm não geralmente são a melhor escolha para essas extensões. Assim, não é surpresa que soluções de farm não pode ser instalado em Microsoft SharePoint Online. Porque a Microsoft trata todo o gerenciamento dos SharePoint Online, não há nenhuma necessidade de extensões administrativas. Para obter mais informações sobre os diferentes conjuntos de APIs no SharePoint e onde elas se sobrepõem, confira Escolher o conjunto de API certo no SharePoint.
Os modelos de objeto do cliente e os pontos de extremidade do REST não duplicam as APIs orientada a administrativas do modelo de objeto de servidor. Além disso, porque nem um Suplemento do SharePoint nem um NCSS pode conter código personalizado que é executado nos servidores SharePoint, eles não é possível chamar essas APIs administrativos. Além disso, todos os recursos no Suplementos do SharePoint devem possuir um escopo de site; e recursos no NCSSs tem o conjunto de sites ou de escopo de site. Assim, uma extensão orientada a administrativas SharePoint não é possível com um Suplemento do SharePoint ou NCSS. Portanto, o segundo princípio, mas não uma regra absoluta, é que suplementos e NCSSs são para usuários finais e soluções de farm são para administradores.
NCSSs de design para extensões de identidade visual e de modelo
Você pode encontrar uma das pequeno número de SharePoint cenários de desenvolvimento para o qual o modelo de suplemento não é adequado, mas que não seja possível implementar com um farm solution ou, talvez porque a solução precisa ser pode ser instalado em SharePoint Online ou precisa estar instalável por um administrador de conjunto de sites. Há duas categorias de amplas e sobrepostas, nesses cenários.
Marca: Os usuários do SharePoint geralmente querem fornecer seus sites do SharePoint, incluindo seus sites do SharePoint Online, uma aparência personalizada com suas próprias cores, estilos, layouts e logotipos. Isso geralmente é mais fácil de fazer com NCSSs do que com suplementos do SharePoint. Um Suplemento do SharePoint tem controle declarativo sobre a aparência de apenas sua própria Web de suplemento. Para a Web do host, ele pode adicionar declarativamente apenas botões de faixa de opções e itens de menu (e partes de suplemento). Qualquer outra alteração em uma Web host ou sua coleção de sites pai, locação ou aplicativo Web doSharePoint local deve ser feita com código ou script que usa um dos modelos de objeto cliente do SharePoint. Por exemplo, novos ícones ou arquivos CSS teriam que ser implantados programaticamente. Esse código pode ser executado no próprio suplemento depois de instalado ou pode ser executado no manipulador de eventos de instalação do suplemento. Mas seria necessário uma quantidade considerável de trabalho para criar esse código. Além disso, o suplemento precisaria de permissões no escopo da coleção de sites para alterar quaisquer sites fora de seu próprio suplemento web e web host, e precisaria de permissões no escopo do locatário para alterar mais do que apenas sua coleção de sites pai. No entanto, um NCSS de identidade visual pode ser implantado e ativado em qualquer coleção de sites; e poderia consistir em apenas alguns componentes puramente declarativos.
Observação
Observe que SharePointsoluções de farm são potencialmente mais eficiente do que NCSSs ou Suplementos do SharePoint de identidade visual, mas não são uma opção no SharePoint Online.
"Semelhantes modelo" extensões: Suponha que você precisa criar uma extensão de gerenciamento de crise para SharePoint para a análise de colaboração e a solução de crises de negócios. Sua extensão inclui vários tipos de lista personalizada, fluxos de trabalho sem código e outros componentes SharePoint, tudo combinados em uma WebTemplate personalizado. Vamos supor que você empacotar e implantar a extensão de um NCSS. Depois que tiver sido ativado o recurso na solução, os usuários podem criar uma subweb de gerenciamento de crise do website SharePoint sempre que ocorre uma crise. Eles podem ser preenchidos no site com dados específicos a crise. Por outro lado, você poderia implementar a mesma extensão Suplemento do SharePoint usando o mesmo conjunto de componentes de SharePoint. Quando o add-in estiver instalado no site da equipe, a subweb (conhecida como "suplemento web") imediatamente é criada. Novamente, os usuários preenchem o site com dados relevantes.
Agora, o que acontece quando ocorre uma segunda crise? Se você implementou a extensão de um NCSS, os usuários podem criar meramente outra subweb do seu WebTemplate personalizado. No entanto, se você implementou a extensão de um Suplemento do SharePoint, os usuários têm um problema. Eles não podem instalar uma segunda instância do suplemento mesmo no site pai. Apenas uma instância de qualquer suplemento pode ser instalada em um web host. Melhor coisa que você pode fazer é criar um subsite do site pai para servir como um local para outra instância do add-in para ser instalado. Quando o add-in estiver instalado, um nova suplemento da web, que é uma sub-subweb do site pai, é criada para os componentes do suplemento. Essa comparação mostra um princípio geral, mas não absoluto,: extensões SharePoint que possuem um caractere "semelhantes modelo" - ou seja, uma coleção reutilizável dos componentes que devem ser configurados para cada caso de uso específico, mas quais naturalmente têm várias instâncias associadas ao site SharePoint mesmo - ajuste melhor desempenho com o modelo de desenvolvimento que NCSS com o modelo de suplemento. Neste exemplo, o elemento variável é a crise, mas é fácil imaginar extensões de modelo semelhantes SharePoint na qual as instâncias variam por região, data ou qualquer número de outras características.
Para obter informações sobre como expandir as possibilidades de suplementos do SharePoint, consulte Usar manipuladores de eventos de suplemento de forma conservadora e suplementos que criam extensões.
Agir como um suplemento
Conforme observado anteriormente, o código personalizado executado nos servidores do SharePoint não é permitido em Suplementos do SharePoint. Essa não é uma limitação significativa. Simplesmente significa que a lógica de negócios personalizada se move "para baixo" para o dispositivo do cliente ou "para cima" para a nuvem. Em ambos os casos, você pode usar o serviço REST/OData do SharePoint para acessar sites, listas e outros dados do SharePoint. Você também pode acessar remotamente os dados do SharePoint por meio dos Modelos de objeto do cliente de SharePoint JavaScript , Silverlight ou .NET Framework. Por fim, em Windows Phones, você pode acessar o SharePoint através do modelo de objeto do SharePoint/Windows Phone. Para obter mais informações sobre os vários conjuntos de APIs no SharePoint, consulte Escolher o conjunto de API correto no SharePoint.
Um ponto semelhante é que os recursos no Suplementos do SharePoint não podem ter escopo de farm, aplicativo web ou conjunto de sites. No entanto, você não precisa dar backup quaisquer elementos (UI) da interface do usuário ou a funcionalidade. Isso significa que a implementação do componente sai do SharePoint e para um cliente ou aplicativo Web remoto ou banco de dados remoto.
A tabela a seguir lista os componentes de SharePoint que não podem ser implantados em um Suplemento do SharePoint e descreve a "forma add-in" de obter a mesma funcionalidade.
| Se quiser que a funcionalidade do... | … Tente essas abordagens. |
|---|---|
| Web Parts personalizadas |
Um Suplemento do SharePoint pode ter páginas remotas que contêm Web Parts personalizadas. Outra opção é expor uma página de um aplicativo Web remoto em uma parte do suplemento em uma página de site do SharePoint. A página remota pode ter basicamente os mesmos controles da interface do usuário e funcionalidade como uma Web Part. Saiba mais em Criar partes de suplementos para instalar com o seu Suplemento do SharePoint. |
| Receptores de eventos e de recursos | Um Suplemento do SharePoint pode conter os receptores de evento remoto funcionalmente equivalentes. Para saber mais, confira Lidar com eventos nos Suplementos do SharePoint. |
| Tipos de campo personalizado (coluna) | Um suplemento pode implantar um novo campo (coluna) baseado em um dos tipos de campo existentes. Os tipos de campo Calculado e Computado são especialmente flexíveis. Outra opção é apresentar os dados em uma página da web remota usando grades ou controles personalizados. |
| Serviços Web personalizados criados na Estrutura de Aplicativos do Serviço do SharePoint | Você pode desenvolver seus serviços web personalizados como serviços remota. |
| Páginas de aplicativo | Um Suplemento do SharePoint pode incluir páginas da web remotas que estão disponíveis a partir de cada site em que o suplemento está instalado. Um suplemento também pode usar qualquer uma das Web Parts internas do SharePoint nas páginas do site. |
Alguns componentes SharePoint, listados abaixo, são usados nos cenários de usuário final, mas não têm equivalentes no modelo de Suplemento do SharePoint e não podem ser implantados em NCSSs. Nesses casos, você deve usar soluções de farm.
- Definições de site personalizado Mas WebTemplates personalizadas, que são funcionalmente semelhantes às definições de site, estão disponíveis no NCSSs e Suplementos do SharePoint. Para obter mais informações, consulte Working with Site Templates and Definitions.
- Controles de representante Para obter mais informações, consulte Delegate Control (Control Templatization).
- Temas personalizados
- Grupos de ação personalizada e ocultando de ação personalizada
- Controles de usuário (arquivos*.ascx) Nenhum cenário realmente requer isso.
Use manipuladores de eventos do suplemento de maneira conservadora
Você pode superar algumas limitações de Suplementos do SharePoint Criando manipuladores para os add-in instalados, suplemento atualizados e suplemento uninstalling eventos. Esses manipuladores são serviços da web hospedadas nos servidores web fora do farm SharePoint, possivelmente na nuvem. Eles podem usar o modelo de objeto do cliente SharePoint, ou as APIs REST, realizar operações CRUD nos componentes SharePoint, incluindo os componentes da web host. Teoricamente, você poderia usar tais manipuladores para superar algumas restrições de implantação nos itens de marcas e extensões de modelo, abordadas anteriormente. No entanto, recomendamos que você use manipuladores de tais somente como último recurso, quando não há outros dar aos clientes a funcionalidade que requer o caso de uso. Ao decidir se deseja criar um manipulador, considere o seguinte:
- A implantação programática na Web host requer que o suplemento solicita a permissão Controle total na Web do host. Suplementos que exigem esse nível de permissão não podem ser vendidos através do Office Store.
- Implantação de componentes na Web host costuma prejudicar as vantagens de segurança de colocar o SharePoint componentes em uma web suplemento com seu próprio domínio.
- Código de implantação extensiva é muito trabalho para criar e depurar comparado com a marcação de implantação descritivo que pode ser usada para o suplemento de web components e em NCSSs.
- Existem algumas práticas recomendadas essenciais que devem ser seguidas na criação de manipuladores de eventos do suplemento. Seu código deve incluir a lógica de reversão para desfazer tudo o que aconteceu se ele encontra um erro. Ele também deve alertá a infraestrutura de SharePoint do erro, para que a infra-estrutura pode reverter tudo o que aconteceu.
- Suplemento manipuladores de eventos não são possíveis com o tipo de Suplemento do SharePoint conhecido como SharePoint-hospedado.
Para obter mais informações sobre manipuladores de eventos de suplemento, consulte o nó SDK Manipular eventos em Suplementos do SharePoint. Para obter informações sobre a lógica de reversão, consulte a seção Adicionar lógica de reversão à seção manipulador do tópico Criar um manipulador para o evento de atualização em Suplementos do SharePoint O último tópico é escrito no contexto do evento atualizado do suplemento, mas os princípios básicos se aplicam a todos os manipuladores de eventos de suplemento.
Suplementos que criam extensões
Outra maneira de usar o modelo de objeto do cliente SharePoint - ou suas APIs REST-- para resolver problemas de implantação do componente com Suplementos do SharePoint, é ter código CRUD dentro o suplemento propriamente dito, em vez de em um manipulador de eventos do suplemento. O suplemento, em seguida, torna-se um tipo de fábrica de um tipo de extensão personalizada. Por exemplo, um suplemento hospedado no SharePoint poderia usar o modelo de objeto do SharePointJavaScript para executar outras operações CRUD e a implantação na web host ou em outro lugar no aplicativo web ou aluguel. Para outro exemplo, confira a seção de Introdução rápida ao provisionamento remoto do fornecimento remoto no SharePoint e técnicas de provisionamento de Site, que descreve como um Suplemento do SharePoint hospedado em provedor é usado para fornecer provisionamento de subweb muito parecido com o do SharePoint na caixa de provisionamento de subweb. No entanto, há muita roda-reinvention e, portanto, muito trabalho na criação de um alocador Suplemento do SharePoint. Além disso, esse tipo de suplemento não pode ser vendido através do Office Store porque o suplemento requer um controle total da web host.