SharePoint 2010 – Melhores práticas:como lidar com montagens [Discussão]

Question

Há uma discussão que vem acontecendo há vários anos quando se programa para SharePoint.

No Visual Studio você pode adicionar uma solução do SharePoint, que será convertida em um arquivo .wsp para implantação.Este arquivo .wsp conterá todos os arquivos de montagem necessários.

Como vocês entregam os arquivos codebehind para:Receptor de eventos, receptor de recursos, página aspx?

Você coloca este arquivo .cs dentro da sua pasta do SharePoint?(desta forma, você também precisará implantar um .dll do seu projeto do SharePoint)

Ou você move toda a lógica do código para um (ou mais) projeto(s) diferente(s) (bibliotecas de classes)?

O que você faz, por exemplo, no segundo exemplo:

• Clique com o botão direito, Adicionar novo item, receptor de evento
• Mova o arquivo .cs para um projeto diferente
• Altere as informações do assembly dentro do arquivo Elements.xml

No primeiro exemplo não movemos esses arquivos, apenas os mantemos enquanto o VS2010 os adiciona.

NÃO estou dizendo qual caminho prefiro, só quero receber muitas contribuições.Não diga apenas "a opção 2 é ruim". Eu realmente gostaria de saber por que e por que não!

Obrigado

EDITAR:

Minha pergunta aqui não tem nada a ver com extensões etc.

Estou falando sobre garantir que sua solução sharepoint NÃO contenha NENHUM arquivo .cs.Dessa forma não é necessário haver assembly no GAC para esta solução.

Exemplo:Eu tenho Customer.SPS.Intranet.Solution (= a solução para gerar WSP, portanto, um item de projeto vazio do SharePoint).

Se eu simplesmente adicionar um recurso e um receptor de recurso, um arquivo .cs será gerado e (após a implantação) um arquivo Customer.SPS.Intranet.Solution.dll será colocado dentro do cache de assembly global.

Isso é o que algumas pessoas não querem!!!(Não entendo porquê, por isso estou pedindo algumas opiniões).

Para resolver isso, eles criam um projeto dentro desta solução chamado:"Customer.SPS.Intranet.Logic", esta solução conterá todos os arquivos codebehind do receptor de recursos.

Isso significa que temos que editar o arquivo feature template.xml para usar a classe receptora localizada no projeto "Logic".Dessa forma mantemos o "Customer.SPS.Intranet.Solution" limpo e só o utilizaremos para empacotamento.Portanto NÃO HAVERÁ um assembly implantado no GAC chamado "Customer.SPS.Intranet.Solution.dll"...em vez disso, um assembly Customer.SPS.Intranet.Logic.dll é implantado no GAC.

Answer 1

Aaah, a eterna questão das soluções e dll's.:-) Por que separar, por que não e quando?Não estou trabalhando no caixa eletrônico, estou de férias, mas como você me pediu para dar uma olhada, vou apenas resumir algumas dicas e minha opinião sobre isso.Portanto, minha resposta é baseada na experiência e visão pessoal.(desculpe StackExhange)

x  Não dividir o "code-behind" e a IU leva a um código difícil de manter.Algo que vi em diferentes projetos é que desenvolvedores inexperientes não lidam bem com "code-behind" (classes C# próximas a XML/ASPX). Eles tendem a escrever mais lógica no code-behind, pois têm acesso direto à UI.Em um projeto específico, vi uma “nova” página de 1.500 linhas (que já é enorme) e a página de “edição” era basicamente um copiar e colar da nova página.Claro que isso é "programação ruim", não é inerente a colocar código ao lado dos artefatos.Mas os maus hábitos são difíceis de mudar e este modelo de trabalho pode ajudar a piorar as coisas.Nesse caso, tornar a classe cs primeiro como um controle e ter algum tipo de classe herdada para a classe de edição teria sido mais fácil de manter.Uma vez criadas, você poderá fazer com que suas páginas asps herdem dessas classes.

x Não dividir o "code-behind" e a UI leva a classes com muita lógica.Outra coisa nesse projeto é que tanto a página nova quanto a página de edição tinham conexões diretas com bancos de dados SQL externos.Eles usaram conexões SQL diretas que criaram uma sobrecarga no código e na manutenção.Uma abordagem em camadas teria ajudado muito.

x Um aplicativo em camadas precisa de montagens separadas.Bem, camadas são boas!Você precisa de uma montagem separada para isso?Não necessariamente.Você pode agrupar sua lógica, camada de acesso a dados, etc. em pastas/namespaces separados em sua montagem.Essas são camadas também."Mas por que eu deveria dividi -los?" Tende a ser uma boa prática.Por que?Bem, você evita o uso acidental de lógica mais profunda (por exemplo, conexões SQL), já que essa lógica só é referenciada em uma camada DA.Outra vantagem é que é potencialmente mais fácil substituir as camadas superiores por outra camada.Digamos outra interface de usuário ou uma interface móvel.Você pode ir ainda mais longe e tornar as camadas inferiores mais genéricas, para que possa reutilizá-las mais tarde.É assim que os frameworks nHibernate e EF podem ser criados.

x "Isso é bom, mas isso é apenas o desenvolvimento do ASP.NET". Certo, mas os mesmos princípios e idéias podem ser usados ​​ao desenvolver artefatos do SharePoint, como os receptores.Por que não trabalhar com receptores genéricos que podem ser parametrizados com propriedades de recursos ou propriedades de pasta?A reutilização da lógica resulta principalmente em soluções mais estáveis.

x A separação incentiva testes (unitários).Depois que você começar a separar e criar classes mais genéricas e assim por diante, não será mais difícil usar interfaces e modelos.Isso significa que os testes unitários serão mais fáceis de implementar (embora devamos realmente usar TDD), pois podemos simular com mais facilidade.Veja a estrutura MVC e como as coisas estão bem separadas.Isso funciona também para o SharePoint.

Então, para resumir meu 2c (e uma mudança ;-)), você pode usar o code-behind diretamente no seu artefato, mas eu prefiro não.Prefiro reutilizar código genérico e testável, do que ter receptores de correspondência automática e código para artefatos (embora você não precise alterar o XML do modelo de recurso no caso manual, basta adicionar o receptor de recurso nas propriedades) e facilidade de localização (eu uso o Go To instantâneo do VS2010) Mas no final é tudo sobre o que você e seu projeto preferem.:-)

Answer 2

Na verdade, pessoalmente, nunca encontrou uma solução em que os arquivos de uma solução do SharePoint foram movidos para fora de um projeto, exceto talvez para situações em que você identificou peças reutilizáveis: e. Métodos de extensão, código de manipulador de eventos base. Há também um motivo para não afastar, e. Normalmente, o VS 2010 usa o GUID com a qual as classes são decoradas para o trabalho interno, conecta o manipulador, para que possa construir dependências corretamente. Além disso, todos os binários, são de qualquer maneira embutidos, portanto, o código - ao lado (não mais código atrás em SP2010) é construído já. Além de registrar a SAFEControls (Web Parts, Controles Personalizados, etc.) não seriam registrados adequadamente, pois o Visual Studio poderia incluir conjuntos externos em seu pacote, mas ele não necessariamente escutaria essas assembléias para o código real - você precisaria fazer tudo isso manualmente - ruim para a produtividade.

Estas são reflexões iniciais, podem voltar com mais algumas, mas a regra inferior: você não está reutilizando essas peças - melhor deixá-las onde vs propõe. Em vez disso, planeje com antecedência que tipo de funcionalidade você implanta, quais dependências você tem, característica escopos, ordem de ativação, etc.

Espero que ajude, C: \ Marius