Entendendo o Desenvolvimento para SharePoint

O SharePoint 2010 possui diversos recursos para customização sem desenvolvimento, com pouco desenvolvimento ou com muito desenvolvimento. Tudo depende da solução proposta para a necessidade de negócio.

É comum ver projetos com problemas de definição do uso de recursos (projetos utilizando recursos que não deveriam ao invés de outros mais adequados), com excesso de desenvolvimento (muito código ao invés de utilizar as funções nativas do SharePoint), entre outros problemas.

A principal causa disso, na minha visão, é a falta de conhecimento do produto e a melhor forma de utilizá-los.

Geralmente o SharePoint é encarado apenas como um produto feito em ASP.NET e com isso entende-se que qualquer desenvolvedor ASP.NET está apto a customizar o SharePoint, sem nem ao menos conhecê-lo. Essas soluções muitas vezes demoram muito para serem criadas e são mais caras, já que tudo é feito novamente ao invés de utilizar recursos nativos.

Mas como resolver esse problema? Não existe milagre, mas algo que eu acredito que funcionaria é dito com uma só palavra: Capacitação.

Neste post vou mostrar alguns conceitos de densenvolvimento para SharePoint e comparar o desenvolvimento com aplicações ASP.NET tradicionais.

Este post faz parte de uma série de posts sobre entendimento do SharePoint 2010, acesse o post principal para ver os outros assuntos: Entendendo o SharePoint 2010

 

Introdução ao Desenvolvimento para SharePoint

 

Soluções Compostas – Arquitetura de Soluções (SharePoint vs ASP.NET Tradicional)

Em um projeto de desenvolvimento de aplicações ASP.NET tradicional, ou outros tipos de projeto como WPF, Windows Forms, Silverlight, PHP, Java, a equipe de desenvolvimento é responsável por criar todas as camadas do sistema como acesso a dados, regras de negócio e interface com o usuário. Mesmo que utilizem algumas APIs desenvolvidas internamente ou externa para ajudar nessas atividades, continuam sendo responsáveis por “tudo”.

Projetos SharePoint tem estrutura diferente, onde contamos com o SharePoint no centro, como se fosse um núcleo e tudo o que for criado para o projeto é acoplado a este núcleo. A equipe de desenvolvimento cria diversos artefatos que isoladamente não fazem muito sentido, mas todas juntas formam a solução para o cliente.

Um exemplo típico de uma solução SharePoint (3 componentes para formar 1 solução):

  • Botões na ribbon para interagir com o usuário, o usuário clica no botão que executa um script em JavaScript que manda parâmetros para uma web part que está em outra página;
  • O usuário abre um formulário InfoPath publicado no SharePoint, preenche os dados e salva o formulário, que ao ser salvo dispara um event receiver com uma regra de negócio customizada que executa um processamento e grava na biblioteca novamente;
  • Diariamente um serviço é executado automaticamente para processar os dados do dia e deixá-los prontos para o usuário poder utilizá-los no dia seguinte;

A imagem 01 mostra a arquitetura tradicional de desenvolvimento de aplicações, onde existem as três camadas (ou N camadas) e os dados são trafegados entre elas. Esta imagem mostra apenas o mais básico da arquitetura de uma aplicação, não é o foco deste artigo falar detalhadamente sobre o assunto. A imagem 02 mostra a arquitetura de aplicações SharePoint, onde o SharePoint é o centro e os componentes são acoplados a ele, veja que para cada camada existem alguns tipos de componentes específicos.

Imagem 01: Arquitetura tradicional de sistemas

Imagem 02: Arquitetura de soluções SharePoint

Observação: neste artigo estou focando em 2 tipos de arquitetura de aplicação: tradicional e SharePoint, mas existe um terceiro cenário que são aplicações que misturam os dois modelos de desenvolvimento, onde o SharePoint é utilizado para hospedar e integrar aplicações ao invés de serem criadas diretamente sobre ele e são somados aos recursos do SharePoint. Acredito que entendendo esses dois modelos sejam suficiente nesta fase inicial.

 

Customizações SharePoint

Os níveis de customização do SharePoint geralmente são divididos em três formas:

  • Customização nativa;
  • Customização simples com código
  • Customização complexas com código.

 

Customizações Nativas

São customizações utilizando os recursos nativos do SharePoint, sem customização com código-fonte, no máximo alguns scripts em JavaScript. O grande foco aqui é utilizar o que está disponível no SharePoint e em outras ferramentas como SharePoint Designer, InfoPath, Visio, Office, etc.

  • SharePoint pelo navegador: por aqui grande parte do SharePoint pode ser customizada como criação de tipos de conteúdo, templates de documentos, listas e bibliotecas nativas, listas e bibliotecas customizadas, ativação/desativação de features, utilização de web parts nativas ou de terceiros, páginas wiki, navegação, estrutura;
  • SharePoint Designer: alteração no layout do site com HTML, javascript e CSS, alteração do conteúdo das páginas, estrutura do site, customização das páginas. Criação de workflows;
  • Administração Central: ativar/desativar serviços, ativar/desativar features, configuração de service applications padrão como busca, sincronização de perfil do usuário;
  • InfoPath: com o InfoPath podemos criar formulário para o usuário sem necessitar de código e de maneira muito rápida e simples. Esses formulários podem conter regras de exibição de conteúdo, validação de dados, conexões externas para obtenção de dados de listas do SharePoint ou de serviços externos, publicando esses formulários no SharePoint.
  • Visio: com o Visio podemos criar diagramas online que busquem informações do banco de dados ou de outras fontes de dados e atualizem-se quando o usuário abrí-los no SharePoint. Um exemplo muito utilizado desse recurso é o monitoramento da estrutura de servidores da empresa. No Visio é criado o diagrama de todos os servidores e conforme o resultado da consulta de dados os servidores online são exibidos na cor verde e os offline na cor vermelha.
  • Office: A partir de botões contindos no Excel (por exemplo) podemos consumir dados diretamente do banco de dados e preencher a planilha para posteriormente salvá-la no SharePoint.

 

Customizações Simples com Código

Customizações feitas com código-fonte, mas que são simples ou geram artefatos isolados ou de pouca relação entre si, por exemplo: criar uma web part pode ser considerada uma solução simples, criar um conjunto de web parts com conexão entre si já é algo mais complexo. O pouco código não significa a quantidade de código, mas sim simplicidade (ausência de complexidade) e pouca interação com outros objetos.

  • Ribbon: a interface do SharePoint 2010 trouxe o conceito de ribbons que apareceu pela primeira vez nos produtos Microsoft no Office 2007. Além dos botões padrão que o SharePoint exibe de forma contextual, podemos criar nossos próprios botões e executar regras e ações customizadas. Como a Ribbon é executada no cliente, sem acionar código no servidor, ela deve ser customizada utilizando JavaScript que, em conjunto com o client object model (modelo de objetos de cliente) do SharePoint, podemos criar regras de negócio que atendam às diversas necessidades. Ao executar uma regra de servidor é possível chamar um serviço em JavaScript ou chamar uma web part em outra página para executar essa regra.
  • Event handler: interceptação de eventos de listas e biblioteca para executar regras customizadas;
  • Web parts: criação de web parts simples para a execução de regras customizadas;
  • SharePoint Designer: customização visual da exibição das listas ou bibliotecas com XLST;
  • Add-In Office: criação e publicação de customizações para serem utilizadas diretamente no Office;
  • Timer jobs: são rotinas que precisam ser executadas periodicamente em determinado tempo, como por exemplo ser executada todo dia às 03:00, ou uma vez por semana, etc. Para esse tipo de customização o SharePoint fornece toda a estrutura de timer jobs necessária.

 

Customizações Complexas com Código

Este tópico trata de soluções complexas feitas com o SharePoint, onde a solução é composta por artefatos mais complexos e maior número de artefatos.

  • Web parts: criação de web parts complexas com conexão entre web parts e regras de negócios mais complexas;
  • Workflows com código: quando workflows criados no SharePoint Designer não satisfazerem as necessidades de negócio é necessário utilizar workflows criados no Visual Studio;
  • Service applications: assim como a busca, perfil de usuários, metadados gerenciados e outros recursos do SharePoint são serviços do “tipo” SharePoint, podemos criar os nossos service applications.

 

Considerações Sobre o Desenvolvimento para SharePoint

O desenvolvimento para SharePoint muitas vezes não é levado com a seriedade necessária. Na minha opinião a melhor forma de desenvolver para SharePoint é não desenvolvendo nada. Quero dizer o seguinte, como o SharePoint é um produto que veio bem preparado para customizações, antes de pensar em desenvolver qualquer tipo de código-fonte pense em resolver as necessidades de negócio utilizando os próprios recursos nativos ou recursos que impactem menos nas tarefas do Sharepoint.

Mas por que evitar desenvolvimento? Porque quanto mais código, mais complexo será o gerenciamento do ambiente, mais tempo do servidor fora do ar para instalar as atualizações, mais tempo de desenvolvimento e implantação, entre outros.

Então isso significa que desenvolver para o SharePoint é ruim? Não, não é isso, muito pelo contrário. O desenvolvimento de soluções com código-fonte para o SharePoint é algo muito comum e necessário. O que estou tentando dizer é que na hora de tomar a decisão sobre qual estratégia de customização será usada, é preciso levar em conta primeiramente os recursos padrões, depois os mais simples e por fim os mais avançados com desenvolvimento.

Anúncios

5 Respostas to “Entendendo o Desenvolvimento para SharePoint”

  1. Entendendo o SharePoint 2010 « Fabian André Gehrke Says:

    […] Fabian André Gehrke SharePoint no dia-a-dia InícioOutras PublicaçõesWP7Sobre Twitter Facebook RSS ← Entendendo o Desenvolvimento para Office 365 Entendendo o Desenvolvimento para SharePoint → […]

  2. Carlos Citrangulo Says:

    Fabian parabéns pelo post, muito bem explicado e organizado.

  3. Entendendo os Papeis dos Usuários no SharePoint « Fabian André Gehrke Says:

    […] para evitar “reconstruir a roda” (não fazer o que já está pronto no SharePoint). No post Entendendo o Desenvolvimento para Sharepoint falei um pouco sobre o […]

  4. Entendendo o SharePoint 2010 « Fabian André Gehrke Says:

    […] Entendendo o Desenvolvimento para SharePoint […]

  5. Boas Práticas de Desenvolvimento de Aplicações SharePoint, Por Que Não Usar? | Fabian André Gehrke Says:

    […] sua maioria web parts, o cuidado acaba sendo menor do que em projetos ASP.NET. Acredito que o post Entendendo o Desenvolvimento para SharePoint possa ajudar a explicar a diferença entre desenvolvimento ASP.NET e SharePoint. Na verdade com o […]


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: