SharePoint 2010 - Mejores prácticas: Cómo manejar conjuntos [Discusión]

Question

Hay una discusión que ha estado ocurriendo para los años de ser servidos al programar para SharePoint.

En Visual Studio, puede agregar una solución de SharePoint, que se convertirá en un archivo .WSP para implementar. Este archivo .WSP contendrá todos los archivos de montaje requeridos.

¿Cómo cuidan los archivos CodeBehind para: receptor de eventos, receptor de características, página de ASPX?

¿Coloca este archivo .cs dentro de su carpeta de SharePoint? (De esta manera, necesitará implementar un .dll de su proyecto de SharePoint, Aswell)

¿O mueve toda la lógica de código a uno (o más) diferentes proyectos (bibliotecas de clase)?

Qué hace, por ejemplo, en el segundo ejemplo:

• Haga clic con el botón derecho, agregue un nuevo elemento, receptor de eventos
• Mover el archivo .cs a un proyecto diferente
• Cambiar la información de ensamblaje dentro del archivo Elements.xml

  En el primer ejemplo, no trasladamos estos archivos, solo manténgalos como vs2010 los agrega.

  No estoy diciendo de qué manera prefiero, solo quiero recibir un montón de entrada. No solo digas "la opción 2 es mala". Realmente me gustaría saber por qué y por qué no!

  gracias

  Editar:

  Mi pregunta aquí no tiene nada que ver con las extensiones, etc.

  Estoy hablando de asegurarse de que su solución de SharePoint no contiene ningún archivo .CS. De esta manera, no tiene que haber una asamblea en el GAC para esta solución.

  Ejemplo: Tengo clientes.sps.intranet.solution (= la solución para generar WSP, por lo que un elemento de proyecto de SharePoint vacío).

  Si simplemente agrego una característica y un receptor de características, se genera un archivo .CS y (después de la implementación) un archivo cliente.sps.intranet.solution.dll se coloca dentro del caché de ensamblaje global.

  ¡Esto es lo que algunas personas no quieren tener! (No entiendo por qué, por eso estoy preguntando algunas opiniones).

  Para resolver esto, crean un proyecto dentro de esta solución nombrada: "Cliente.sps.intranet.logic", esta solución contendrá todos los archivos de CodeBehind del receptor de características.

  Esto significa que tenemos que editar el archivo Template.xml para usar la clase del receptor ubicado en el proyecto "LOGIC". De esta manera, mantenemos la limpieza del "cliente.sps.intranet.solution" y solo lo usaremos para el embalaje. Por lo tanto, no habrá una asamblea desplegada en el GAC llamado "Cliente.sps.intranet.solution.dll" ... en su lugar, un cliente.sps.intranet.logic.dll. El ensamblaje se implementa en el GAC.

Answer 1

aaah, la cuestión eterna de soluciones y DLL's. :-) ¿Por qué dividirse, por qué no, y cuándo? No estoy trabajando en cajeros automáticos, estoy de vacaciones, pero como me pediste que echara un vistazo, simplemente resumiré unas cuantas láminas y mi opinión. Así que mi respuesta se basa en la experiencia personal y la vista. (Lo siento StackExHange)

x no dividiendo "el código detrás" y la interfaz de usuario conduce al código difícil de mantener. Algo que vi en diferentes proyectos es que los desarrolladores inexpertos no hacen frente a "Código detrás" (clases C # junto a XML / ASPX), tienden a escribir más lógica en el código detrás, ya que tienen acceso directo a la UI. En un proyecto en particular, vi una página "nueva" de 1500 líneas (que ya es enorme) y la página "Editar" fue básicamente una copia y pasta de la nueva página. Seguro que esta es "mala programación", no es inherente a poner un código detrás de lado a los artefactos. Pero los malos hábitos son difíciles de cambiar y este modelo de trabajo puede ayudar a empeorar las cosas. En este caso, lo que hace que la clase CS sea primero como un control y tener algún tipo de clase heredada para la clase de edición, habría sido más fácil de mantener. Una vez creado, podría hacer que sus páginas de ASPS heredan de estas clases.

x no dividiendo "código detrás" y ui conduce a clases con demasiada lógica. Otra cosa en ese proyecto es que tanto la nueva página como la página de edición tenía conexiones directas a bases de datos externas de SQL. Usaron conexiones SQL directas que crearon una sobrecarga de código y mantenimiento. Un enfoque en capas habría ayudado enormemente.

x Una aplicación en capas necesita ensamblajes separados. Bueno, la capa es buena! ¿Necesita un montaje separado para ello? No necesariamente. Puede agrupar su lógica, capas de accidentes de datos, etc. en carpetas / espacios de nombres separados dentro de su ensamblaje. Esas son capas también. "¿Pero por qué debería dividirlos?" Tiende a ser una buena práctica. ¿Por qué? Bueno, evita el uso accidental de la lógica más profunda (por ejemplo, conexiones SQL), ya que la lógica solo se hace referencia en una capa DA. Otra ventaja es que es potencialmente más fácil reemplazar las capas superiores por otra capa. Diga otra interfaz de usuario o una interfaz móvil. Puede empujarlo aún más y hacer capas más bajas más genéricas, para que pueda volver a usarlas más adelante. Así se pueden crear los marcos nhibernate y EF.

x "Eso es bueno, pero eso es solo el desarrollo de ASP.NET". Derecho, pero se pueden usar los mismos principios e ideas al desarrollar artefactos de SharePoint, como los receptores. ¿Por qué no trabajar su camino a los receptores genéricos que pueden ser parametrados con las propiedades de las características o las propiedades de la carpeta? Reutilizar la lógica en su mayoría resulta en soluciones más estables.

x separación fomenta la prueba (unidad). Una vez que comience a separar y crear una clase más genérica, etc., ya no es un largo tramo para usar interfaces y modelos. Esto significa que las pruebas de la unidad serán más fáciles de implementar (aunque en realidad deberíamos usar TDD), ya que podemos burlarnos más fácilmente. Mire el marco de MVC y cómo las cosas están muy bien separadas. Esto funciona también para SharePoint.

Para resumir mi 2C (y un cambio ;-)), puede usar el código detrás de la marea directamente a su artefacto, pero prefiero no. Prefiero ir por reutilización, código genérico y comprobable, que tener receptores y código automáticos de coincidencia para artefactos (aunque no necesita cambiar la plantilla XML de la característica en el caso del manual, ya que simplemente agrega el receptor de características en las propiedades) y La facilidad de localizar (uso el instante en VS2010), pero al final se trata de lo que prefiere usted y su proyecto. - -)

Answer 2

En realidad, personalmente, nunca encontró una solución donde los archivos de una solución de SharePoint se han movido fuera de un proyecto, excepto tal vez para situaciones en las que ha identificado piezas reutilizables: por ejemplo. Métodos de extensión, código de control de eventos básicos. También hay una razón para no moverlo, por ejemplo. Por lo general, VS 2010 usa el GUID con el que las clases están decoradas para trabajar internas en él conecta el manejador, por lo que podría acumular dependencias correctamente. Además, todos los binarios, están construidos de todos modos, por lo tanto, el código, al lado (no más código, detrás en SP2010) ya está construido. Además, el registro de SafeControls (partes web, controles personalizados, etc.) no estaría registrada correctamente, ya que Visual Studio podría incluir ensamblajes externos en su paquete, pero no necesariamente exploraría a esas asambleas para el código real, deberías hacer todo eso. manualmente - malo para la productividad.

Estas son las reflexiones iniciales, podrían regresar con un poco más, pero la regla inferior: no está reutilizando esas piezas, entonces mejor déjalos donde se propone VS. Más bien, planifique qué tipo de funcionalidad se despliega, qué dependencias tiene, presentan los ámbitos, orden de activación, etc.

espero que ayude, C: \ marius